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

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

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. Когда функция вам не мешает. То есть не следует проводить рефакторинг ради рефакторинга, маниакально выискивая «плохие» места в коде. Куда разумнее улучшать код только после того, как наткнулся на него в рамках какой–то задачи или более крупного рефакторинга.

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

Удобно когда всё в одном файле и ничего искать не нужно? С одной стороны, конечно, да. Но это справедливо только для весьма небольших проектов.

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

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

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