Книга: Рефакторинг. Зачем?

Когда не следует выделять функцию

Когда не следует выделять функцию

Дабы не впадать в крайности, просто необходимо написать также и эту главу. Правила и рекомендации — это замечательно, но никогда не стоит забывать, что главное для нас не методичное соблюдение всех правил, а чистый, понятный код.

Попробую привести несколько примеров, когда выделение функции, как правило, делает только хуже.

1. Процедура выбора из однотипной информации. Как правило, такая проблема возникает в конструкциях case (switch для C-подобныхьязыков) или «if … then … else if … then … else if … then …». Данные блоки могу включать в себя десятки, сотни и даже тысячи условий, занимая, разумеется, значительно больше одного экрана, но, разбивать такие блоки всё–таки не стоит.

Это справедливо для блоков с именно однотипными проверками. Если условия можно как–то сгруппировать, то можно каждую группу вынести в свою функцию (например, слова на букву «А» обрабатывает одна функция, на «Б» — другая и так далее).

2. Функции с действительно сложной логикой, как правило, также не удаётся красиво разбить на более мелкие составляющие. И проблема тут даже не в сложности как таковой, а в том, что не всему можно дать название. Бывает, что совершается настолько специфичное действие, что как не назови, всё равно понятно не будет.

3. Математические выражения также редко удаётся разбить на составляющие. Например, если вы что–то считаете по формуле — вам будет крайне сложно придумать адекватное название для расчёта части этой формулы.

4. Когда функция вам не мешает. То есть не следует проводить рефакторинг ради рефакторинга, маниакально выискивая «плохие» места в коде. Куда разумнее улучшать код только после того, как наткнулся на него в рамках какой–то задачи или более крупного рефакторинга.

Причин так говорить у меня сразу несколько. Во–первых, если вы раньше не натыкались на фрагмент кода, то может и в будущем никогда не наткнётесь, зачем же тратить на него время, если он нормально работает и пока никому не мешает? Во–вторых — не стоит забывать, что любой рефакторинг, как бы аккуратно он не проводился — это риск что–то испортить. Опять же, зачем рисковать просто так? Ну и наконец, всегда есть вероятность, что после рефакторинга вы через какое–то время поймёте, что логику надо поменять, а может и вовсе помножить на ноль эту ветку кода и что получится? Вы потратили время на улучшение уже устаревшего кода, то есть впустую, а могли, например, лишний раз протестировать функциональность или написать пару тестов.

Оглавление книги