Рефакторинг методов в существующей кодовой базе с огромным количеством параметров

Question

Я унаследовал существующую кодовую базу, в которой «особенности» следующие:

• огромные монолитные классы с (буквально) сотнями переменных-членов и методов, которые идут по одному для страниц (например, экраны))
• публичные и приватные методы с большим количеством аргументов.

Я пытаюсь очистить и реорганизовать код, чтобы оставить его немного лучше, чем я его нашел.Так что мои вопросы

• стоят того (или вы) методов рефакторинга с 10 или около того аргументами, чтобы они были более читабельными?
• Существуют ли лучшие методики определения продолжительности методов?Как долго вы обычно их держите?
• плохие монолитные классы?

Answer 1

стоит (или вы) методов рефакторинга с 10 или около того аргументами, чтобы они были более читабельными?

Да, оно того стоит. Как правило, более важно реорганизовать методы, которые не являются «разумными», чем методы, которые уже хороши, коротки и имеют небольшой список аргументов.

Обычно, если у вас много аргументов, это потому, что метод делает слишком много - скорее всего, это должен быть собственный класс, а не метод.

При этом в тех случаях, когда требуется много параметров, лучше всего инкапсулировать параметры в один класс (т.е.: SpecificAlgorithmOptions) и передать один экземпляр этого класса. Таким образом, вы можете обеспечить чистые значения по умолчанию, и совершенно очевидно, какие методы необходимы, а не дополнительные (в зависимости от того, что требуется для создания класса параметров).

Существуют ли лучшие методы определения продолжительности методов? Как долго вы их обычно храните?

Метод должен быть максимально коротким. Он должен иметь одну цель и, по возможности, использоваться для одной задачи. Если возможно разделить его на отдельные методы, каждый из которых представляет собой реальную качественную «задачу», то сделайте это при рефакторинге.

плохие монолитные классы?

Да.

Answer 2

если код работает и нет необходимости его трогать, я бы не стал рефакторинг. Я только рефакторинг очень проблемных случаев, если я все равно должен коснуться их (либо для расширения их для функциональности или исправления ошибок). Я предпочитаю прагматичный способ: только (в 95%) коснуться того, что вы меняете.

Несколько первых мыслей о вашей конкретной проблеме (хотя в деталях это трудно, не зная кода):

• начать группировать переменные экземпляра, затем эти группы будут предназначены для «извлечения класса»
• сгруппировав эти переменные, можно надеяться, что вы можете сгруппировать некоторые методы, которые также будут перемещены при выполнении «извлечения класса»
• часто есть много методов, которые не используют никаких полей. сделать их статическими (они, скорее всего, являются вспомогательными методами, которые можно извлечь в вспомогательные классы.
• в случае, если несвязанные поля экземпляра смешаны во многих методах, загрузите «метод извлечения»
• по возможности используйте инструменты автоматического рефакторинга, потому что у вас, скорее всего, нет тестов, а автоматизация более безопасна.

Относительно ваших других конкретных вопросов.

стоит (или вы) методов рефакторинга с 10 или около того аргументами, чтобы они были более читабельными?

Определенно. 10 параметров слишком много, чтобы понять нас, людей. скорее всего, метод делает слишком много.

Существуют ли лучшие методы определения продолжительности методов? Как долго вы их обычно храните?

это зависит ... от предпочтений. я сказал кое-что в этом потоке (хотя вопрос был PHP). тем не менее я бы применил эти числа / метрики к любому языку.

монолитные классы плохие?

это зависит от того, что вы имеете в виду под монолитным. если вы имеете в виду много переменных экземпляра, бесконечные методы, много сложностей if / else, да.

также взглянем на настоящую жемчужину (для меня это обязательно для каждого разработчика): эффективная работа с устаревшим кодом

Answer 3

Предполагая, что код работает, я бы посоветовал вам сначала подумать над этими вопросами:

• хорошо ли задокументирован код?
• ты понимаешь код?
• как часто добавляются новые функции?
• как часто сообщают об ошибках и исправляют их?
• насколько сложно изменить и исправить код?
• каков ожидаемый срок действия кода?
• Сколько версий компилятора у вас позади (если вообще)?
• Ожидается ли изменение ОС, на которой он работает, в течение срока службы?

Если система будет заменена через пять лет, хорошо документирована, претерпит мало изменений, и ошибки легко исправить - оставьте это в покое независимо от размера классов и количества параметров. Если вы решили провести рефакторинг, составьте список своих предложений по рефакторингу в порядке максимальной выгоды с минимальными изменениями и атакуйте его постепенно.