Рефакторинг методов в существующей кодовой базе с огромным количеством параметров
Я наследовал существующую кодовую базу, где "функции" следующие:
- огромные монолитные классы с (буквально) 100's членских переменных и методов, которые идут один для страниц (er. экраны)
- открытые и закрытые методы с большим количеством аргументов.
Я пытаюсь вымыться и осуществить рефакторинг код, оставить его немного лучше, чем, как я нашел его. Так мои вопросы
- это стоит (или Вы) осуществляют рефакторинг методы приблизительно с 10 аргументами так, чтобы они были более читаемыми?
- есть ли лучшие практики на том, какой длины методы должны быть? Сколько времени Вы обычно сохраняете их?
- монолитные классы плохо?
3 ответа
стоит (или стоит) переписать методы рефактора с 10 или около того аргументами, чтобы они были более читабельными?
Да, стоит. Как правило, более важным является использование методов рефактора, которые не являются "разумными", чем методы, которые уже являются хорошими, короткими и имеют небольшой список аргументов.
Обычно, если у вас много аргументов, то это связано с тем, что метод делает слишком много - скорее всего, это должен быть не метод, а собственный класс.
При этом в тех случаях, когда требуется много параметров, лучше всего инкапсулировать параметры в один класс (т.е. SpecificAlgorithmOptions) и передать один экземпляр этого класса. Таким образом, можно обеспечить чистые настройки по умолчанию, и совершенно очевидно, какие методы являются существенными, а какие необязательными (исходя из того, что требуется для построения класса опций).
существует ли лучшая практика, как долго должны быть методы? Как долго вы их обычно храните?
Метод должен быть как можно короче. Он должен иметь одну цель и использоваться для одной задачи, когда это возможно. Если его можно разделить на отдельные методы, где каждый как реальная, качественная "задача", то сделайте это при рефакторинге.
плохи ли монолитные классы?
Да.
Предполагая, что код работает, я бы предложил сначала подумать над этими вопросами:
- хорошо ли документирован код?
- понимаете ли вы код?
- как часто добавляются новые возможности?
- как часто сообщают об ошибках и исправляют их?
- насколько сложно модифицировать и исправлять код?
- какова ожидаемая продолжительность жизни кода?
- сколько версий компилятора вы поддерживаете (если вообще поддерживаете)?
- ожидается ли, что операционная система, на которой она работает, изменится за время своей жизни?
Если система будет заменена через пять лет, хорошо документирована, претерпит незначительные изменения, и ошибки легко исправляются - оставьте это независимо от размера классов и количества параметров. Если вы решили сделать список ваших предложений по рефакторингу в порядке максимальной выгоды с минимальными изменениями и атаковать его инкрементально.
Если код работает и трогать его не нужно, я бы не стал проводить рефакторинг. Я реорганизую только очень проблемные случаи, если мне все равно придется их трогать (либо для расширения их функциональности, либо для исправления ошибок). Я предпочитаю прагматичный подход: трогайте только (в 95%) то, что вы меняете.
Некоторые первые мысли о вашей конкретной проблеме (хотя подробно это сложно, не зная кода):
- начните группировать переменные экземпляра, эти группы затем будут нацелены на выполнение «извлечения класса»
- при группировке эти переменные вы, надеюсь, сможете сгруппировать некоторые методы, которые также будут перемещены при выполнении 'extract class'
- . Часто бывает много методов, которые не используют никаких полей. сделайте их статическими (скорее всего, это вспомогательные методы, которые могут быть извлечены во вспомогательные классы.
- В случае, если несвязанные поля экземпляра смешаны во многих методах, загружайте ли «метод извлечения»
- инструменты автоматического рефакторинга) насколько это возможно, потому что у вас, скорее всего, нет тестов, а автоматизация более безопасна.
Что касается других ваших конкретных вопросов.
стоит (или вам) рефакторинг методов с 10 или около того аргументами, чтобы они более читабельны?
определенно. 10 параметров - это слишком много, чтобы понять нас, людей. скорее всего, метод делает слишком много.
есть ли лучшие практики относительно того, как долго должны быть методы? Как долго вы обычно их храните ?
это зависит ... от предпочтений. Я изложил некоторые вещи в этой ветке (хотя вопрос был о PHP). Тем не менее, я бы применил эти числа / метрики к любому языку.
являются монолитными классы плохие?
это зависит от того, что вы имеете в виду под монолитным. если вы имеете в виду множество переменных экземпляра, бесконечные методы, много сложностей if / else, да.
также взгляните на настоящую жемчужину (на мой взгляд, она должна быть у каждого разработчика): эффективно работает с устаревшим кодом