Рефакторинг — изменение исходного кода программы, чтобы он стал проще и понятнее.
Сразу оговоримся, что рефакторинг не предназначен для исправления ошибок или добавления новой функциональности, он в целом не меняет поведение программного кода, а делает его понятным и пригодным для развития проекта.
Рефакторинг чаще требуется большим долгосрочным проектам, в которых постоянно происходят доработки, добавляются новые интеграции со сторонними системами, модифицируются сценарии пользователя, добавляется новый функционал. Чаще всего, все эти доработки выглядят в коде как «заплатки»: они обычно несогласованны между собой. Из-за этого сайт может хуже работать, а в какой-то момент и вовсе сломаться.
Необходимость рефакторинга ― огромная проблема как разработчиков, так и заказчиков. Заказчик должен понимать важность этой работы, т.к. от этого зависит производительность проекта ― сайта, интернет-магазина, маркетплейса, b2b-портала.
Заказчики редко выделяют деньги на рефакторинг, и это боль разработчиков, которые долгосрочно поддерживают проект. Если проектом с нуля занимается не просто одна компания-подрядчик, а выделенная команда разработчиков, то работать без рефакторинга сложно, но возможно: все члены команды хорошо ориентируются в коде и достаточно быстро закрывают задачи по проекту. Но и это не освобождает проект от необходимости рефакторинга.
Как понять, что проекту нужен рефакторинг
Заказчику стоит задуматься о рефакторинге, если:
- проект работает, но медленнее обычного, часто случаются сбои;
- даже небольшие правки затягиваются по времени;
- разработчики не могут оценить объем задач, поскольку говорят о том, что сначала нужно разобраться;
- при выгрузке изменений в релиз часто встречают баги.
Для разработчика «красные флаги», сигнализирующие о необходимости чистки кода будут такими:
- дублирование кода;
- длинные или ресурсоемкие методы;
- большие классы;
- несгруппированные данные;
- длинные списки параметров;
- избыточные переменные;
- если понимание кода занимает много времени. Иногда код может быть написан с соблюдением принципов DRY и KISS, но работа кода всё-равно остается непонятной разработчикам. Здесь стоит задуматься о смене паттернов проектирования и проектировании другой модели абстракции. Часто помогает и переименование переменных по рекомендациям Мартина Фаулера.
В рамках рефакторинга проводятся, на первый взгляд, элементарные работы:
- перемещение поля из одного класса в другой;
- вынесение фрагмента кода из метода в самостоятельный метод;
- перемещение кода по иерархии классов.
Однако совокупный эффект таких малых изменений в состоянии радикально улучшить весь проект.
Пример рефакторинга
Для проекта «Личный кабинет студента РЭА им. Г.В. Плеханова» мы провели рефакторинг импорта данных из 1С на сайт. Всего импортируется 16 разных сущностей. До рефакторинга был реализован последовательный импорт. Это значит, что пока в обработке находился один файл импорта, остальные файлы не импортировались. Все это приводило к задержке в обработке данных.
После проведения рефакторинга каждая импортируемая сущность запускается отдельными cron-задачами. Кроме того, была сделана разбивка импорта на параллельные потоки с гибкой настройкой их количества для одной сущности.
Благодаря этому скорость обработки импортируемых данных увеличилась в 3 раза.
Таким образом мы не просто улучшили читаемость кода, но и изменили поведение системы: сделали ее более оптимальной в отдельно взятых блоках функциональностей.
Рекомендации
Прежде всего, советуем прочитать книгу Мартина Фаулера «Рефакторинг. Улучшение проекта существующего кода». Там много внимания уделяется рассмотрению причин для проведения рефакторинга.
Рекомендации, данные ниже, в большей мере будут актуальны владельцам крупных проектов, которые постоянно дорабатываются и развиваются.
- Заложить в бюджет хотя бы минимальные работы по рефакторингу.
- Заниматься рефакторингом регулярно, а не от случая к случаю.
- Включать в рефакторинг написание автотестов.
- Проектировать код таким образом, чтобы рефакторинг не требовался долгое время.
- Делать работы по рефакторингу в период затишья, а не в процессе активных доработок проекта.