Рефакторинг кода: от причин включить его в цикл разработки до конкретных техник и инструментов

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

Читайте также:

Разработка и масштабирование высоконагруженных веб-систем: технические аспекты и вызовы.

Архитектура веб-проекта: для чего она нужна.

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

Со стороны неспециалиста может показаться, что в рефакторинге нет смысла. До и после все работает одинаково, значит, можно обойти этот этап и не тратить на него время и деньги. Особенно когда продукту есть куда расти: есть конкретный список того, что нужно исправить, добавить, изменить в продукте. На самом деле именно наведение порядка в кодовой базе в перспективе удешевляет и ускоряет внесение в него изменений, отражающихся на его функциональности и возможностях.

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

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

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

Любой цифровой продукт, например, высоконагруженная система для автоматизации предприятия или электронная торговая площадка, ценен потому, что решает конкретную задачу бизнеса. Сам по себе программный код никому не нужен, нужны инструменты для решения проблем и задач. Потому программный продукт, который решает поставленную задачу, по умолчанию написан и работает как надо.

По мере развития проекта, роста бизнеса, изменения рынка требования к программным решениям неизбежно меняются. Всего каких-то 10 лет назад — в середине 2010-х — информацию и товары искали чаще с ноутбуков и компьютеров, чем с мобильных. «Смартфонизация» привела к тому, что сайты стали в первую очередь делать удобными для сенсорных экранах телефонов. Можно ли в таком случае считать неправильно сделанными интернет-магазины без мобильной версии, запущенные в начале прошлого десятилетия?

Тройка основных причин для рефакторинга, начиная с самой распространенной, выглядит так:

1. Изменились требования.
2. Поменялись стандарты и технологии.
3. Код тяжело читать, расширять, тестировать.

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

Разработка программного продукта всегда происходит с учетом текущих потребностей и ограничений. Никто намеренно не стремится написать код так, чтобы потом часами переписывать его для упрощения, повышения читабельности для упрощения самим себе его обслуживания, поддержки и масштабирования. Просто технологии развиваются, рынок меняется, а вместе с ним и требования. Это как с ремонтом в квартире: нельзя сделать его один раз так, чтобы ничего не ломалось, не изнашивалось, никогда не приходилось ничего менять, доделывать и обновлять.

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

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

В одной из используемых командой разработчиков «АйТи-Баланса» методологии Agile рефакторинг заложен в повторяющийся цикл работы с кодом: Red-Green-Refactor. Вкратце: сначала пишется тест, который ожидаемо не будет пройден, потом под него функциональность, а когда тестирование даст «зеленый» результат написанное подлежит рефакторингу в пользу упрощения и оптимизации.

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

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

Основной инструмент рефакторинга — автотесты и автоматизация вообще. В налаженном процессе рутинные задачи решает компьютер, например, через CI/CD (Continuous Integration/Continuous Deployment). GitHub Actions, Gitlab CI/CD или не менее популярный и универсальный Jenkins избавляет от необходимости после каждого внесенного изменения тратить время на проверку не сломалось ли чего.

Внедрение автоматизации в процесс разработки на старте требует времени, зато экономит его в перспективе. Особенно когда проект растет и в процессе работы все чаще случаются ситуации, когда нужно выбирать между «запустить быстро» и «сделать основательно». Именно благодаря грамотному CI/CD в таких ситуациях удается обойтись без избыточного накопления техдолга и ускорить разработку.

Изменения кода, даже незначительные, могут что-то сломать в проекте. Чтобы этого не случилось, редактируемый код плотно покрывают автотестами, а рефакторинг сопровождают многоуровневым код-ревью.

Рефакторинг иногда «съедает» слишком много времени. Чтобы избежать, надо устанавливать рамки, четко определять цели и критерии эффективности (KPI) рефакторинга.

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

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

У нас в «АйТи-Балансе» коммуникация в командах и процессы построены таким образом, чтобы минимизировать риск столкнуться с проблемами на каждом этапе работы над программным продуктом. Мы с 2013 года разрабатываем программное обеспечение от IT-аудита до создания высоконагруженных систем с применением ИИ. Подробнее о том, как работаем, с упором на решение задач вашего бизнеса и разработку нужного вам программного продукта, наш коллега сможет рассказать на консультации или демонстрации.