Рефакторинг. Зачем? - [4]

Выделение функции в процессе написания

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

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

Как же писать «короткими фразами»? Разумеется, в первую очередь, это дело привычки. Не думаю, что мне будет по силам формализовать этот процесс, я лишь попробую передать свои ощущения о том, как можно себе помочь.

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

Например, вы говорите себе: «если точка внутри прямоугольника, то» и при этом пишите: «if (x >= Rect. Left) and (x <= Rect. Right) and (y >= Rect. Top) and (y <= Rect. Bottom) then». Кто мешает вам написать сразу «if PointOnRect(x, y, Rect) then»? И не важно, что у вас пока нет функции PointOnRect, вы её легко напишите следующим шагом. А если даже забудите — комптлятор вам подскажет.

2. Попытайьесь ещё до того, как начнёте писать код, разбить большое действие на составляющие. Банальный пример, о котором мы уже говорили — рассчёт суммы периметров. Его очень просто разбить на два действия — расчёт периметра одного поямоугольника и вычисление суммы этих величин.

3. Если объединить этот пункт с предыдущим, можно сформулировать такой приём программирования, как использование ещё не существующих функций.

begin
Rect:= ПолучитьПрямоугольник;
Point:= ПолучитьТочку;
if ТочкаВПрямоугольнике(Point, Rect) then
ДобавитьТочку(Point);
end;

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

Сам устыдился своих упрёков и решил перевести в тот код, который сам бы и написал:

begin
Rect:= GetRect;
Point:= GetPoint;
if PointOnRect(Point, Rect) then
 AddPoint(Point);
end;

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

Пользуясь случаем, приведу ещё один довод в пользу коротких функций. Как правило, они более конкретны. То есть не «делают то, то и ещё это за одно», а делают что–то одно и только это. Так вот, если принять во внимание, что не бывает код без ошибок, а это вообще говоря так и есть, возникает проблема: как узнать правильно работает функция или нет. Разве легко это сделать, если назначение функции не совсем понятно? Чем больше у вас кода, правильную работу которого легко проверить, тем лучше.

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

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

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

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

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

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

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

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

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