В сфере IT-разработки довольно часто можно услышать термин «рефакторинг». Многие считают, что это процесс исправления ошибок или модификации продукта, однако это не так. Под рефакторингом понимают переработку программного кода, в результате которой он становится более понятным и простым для восприятия.
Зачем нужен рефакторинг
Если код хорошо структурирован и легко воспринимается другими программистами, то его поддержка и доработка не вызывает особых трудностей. Однако добиться такого результата с первого раза удается далеко не всегда. Чаще всего разработчики торопятся, поскольку в процессе работы меняются требования и задачи, а сроки сдачи проекта остаются прежними. Более того, после тестирования находятся баги, которые нужно оперативно исправлять.
Как итог – код становится сложным, громоздким и непонятным. Даже хорошо структурированный исходник не исправит ситуацию. Разработчики прекрасно знают о существовании этой проблемы, ведь запутаться можно не только в чужом, но и в своем коде.
Решить проблему помогает рефакторинг. С его помощью можно:
- сделать код удобочитаемым для любого участника команды, тем самым упростить дальнейшую разработку;
- ускорить процесс работы над проектом;
- сократить время поиска ошибок;
- сохранить исходную архитектуру программы, сделав при этом ее структурированной.
IT-сфера постоянно развивается и языки программирования не исключение. Добавляются новые библиотеки, фреймворки, операторы и функции, значительно упрощающие код и т.д. В итоге программы постепенно устаревают. Тот функционал, который еще год назад занимал 50 строк кода, сегодня может быть реализован намного компактнее.
Любым, даже самым совершенным приложениям, рано или поздно потребуется рефакторинг, с помощью которого устаревшие участки будут обновлены. Важно понимать, что с программным кодом взаимодействует не только компьютер, но и люди, которые будут поддерживать его работоспособность и обновлять. Примеры, когда разработчикам приходится целыми неделями разбираться в чужом коде – не редкость. Чтобы такого не случалось нельзя забывать про рефакторинг.
Отличие рефакторинга от оптимизации
Рефакторинг и оптимизация являются для многих синонимичными понятиями. Во многом из-за того, что оба процесса часто проводятся одновременно. Однако у них совершенно разные задачи. Оптимизация направлена на качественный рост производительности, а рефакторинг – на улучшение понятности кода.
Оптимизация часто усложняет код, и это нужно учитывать. Рефакторинг, в свою очередь, упрощает программу, в результате чего могут вырасти показатели производительности.
Когда нужно улучшать код
На необходимость проведения рефакторинга указывают следующие признаки:
- невозможность определить временные рамки выполнения определенной задачи;
- идентичные изменения приходится дублировать в нескольких местах программного кода;
- несмотря на то, что программа работает, любые доработки занимают много времени, поскольку каждый раз приходится разбираться в коде.
Пренебрегать рефакторингом не стоит, поскольку плохо структурированный код не несет никакой пользы проекту и только тормозит его реализацию. Более того, улучшать его качество нужно постоянно, например, после добавления новой функции или метода.
Как происходит рефакторинг
Рефакторинг – это небольшое, но регулярное улучшение кода. Перед его проведением нужно определить основные проблемы, которые необходимо устранить. Чаще всего, это:
- дублирование – одинаковый код выполняет одни и те же действия в нескольких местах программы. Данную часть лучше вынести в отдельную функцию;
- слишком длинные классы – если длина превышает 30 строк, лучше разбить его на несколько мелких классов;
- мертвый код – после внесения изменений переменная, класс или метод больше не используется, но код остается нетронутым. От таких участков надо сразу избавляться. Довольно часто такую ситуацию можно встретить в сложных условных конструкциях, где одна из веток никогда не исполнялась, но соответствующий код так и не был удален;
- некорректно названные переменные – имена должны сообщать, что хранится в данной переменной и для чего она существует. Это правило также справедливо для функций и классов. Например, переменную, обозначающую минимальную длину не стоит называть «a» или «b», правильнее будет minLength;
- слишком длинные методы и функции – все то же самое, что и с классами. Оптимальный размер – 20-30 строк, не более. Если сократить не получается, лучше разделить функцию на несколько небольших процедур;
- обилие параметров у методов или функций – чем их больше, тем легче запутаться. Если каждый параметр действительно необходим, их стоит вынести в отдельную структуру, у которой должно быть понятное имя;
- большое количество комментариев – ими стараются скрыть недостатки плохого кода. Если при написании какого-то участка, появляется желание написать поясняющий текст, стоит попробовать переписать код таким образом, чтобы он стал более понятен. Программа, переполненная комментариями, плохо воспринимается.После внесения правок, стоит обратить внимание на другие участки кода, прежде всего на те, которые давно не редактировались. Высока вероятность того, что они стали некорректными и требуют исправления.
Внесение любых изменений означает проведение нового тестирования. Поэтому, прежде чем приступать к рефакторингу, стоит подготовить интеграционные, модульные и функциональные тесты. Поскольку рефакторинг предполагает внесение небольших изменений, ошибки довольно легко обнаружить.
Чистка кода проводится на этапе тестирования, когда основная разработка подошла к концу и остаётся лишь проверить работоспособность. На этой стадии разработчики исправляют баги, найденные таксировщиками, и параллельно занимаются рефакторингом.
Руководители проектов, обычно, понимают всю важность рефакторинга и включают его в процесс разработки. Особенно, это актуально в сфере экстремального программирования, где разработчики постоянно проводят рефакторинг и тестирование написанного ранее кода.
