Рефакторинг

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

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

Ловушек две. Первая — «большой рефакторинг» отдельной веткой на три месяца: пока команда переписывает, продуктовая разработка идёт в основной ветке, и слияние в конце превращается в отдельный проект с собственными рисками. Гораздо безопаснее мелкими шагами, каждый из которых доезжает до продакшена. Вторая — рефакторинг вместо решения. Если архитектура принципиально не подходит под задачу, косметическая перестановка модулей не поможет: нужно либо менять архитектуру осознанно, либо признать, что систему проще заменить.

Смежные термины

• Технический долгТехнический долг — накопленная разница между тем, как система устроена, и тем, как она должна быть устроена: каждое упрощение ради срока превращается в постоянную надбавку к стоимости и срокам всех последующих задач.
• Легаси-кодЛегаси-код — работающий код, который дорого менять: он написан на устаревшем стеке, не покрыт тестами или потерял авторов, поэтому любая правка требует восстанавливать логику по исходникам и грозит поломкой в непредсказуемом месте.
• CI/CDCI/CD — конвейер, который на каждый коммит автоматически собирает проект, прогоняет тесты и проверки, а затем выкладывает прошедшую сборку на тестовый стенд или в продакшн, убирая ручной деплой вместе с человеческим фактором.
• МонолитМонолит — приложение, которое собирается и разворачивается одним куском: весь код лежит в общем репозитории и выполняется в одном процессе, работает с одной базой и выкатывается целиком, что даёт простоту разработки ценой связанности.
• МикросервисыМикросервисы — архитектура, где приложение разбито на несколько самостоятельных сервисов со своими базами и релизным циклом: они общаются по сети через API, деплоятся независимо и масштабируются по отдельности, но требуют зрелой инфраструктуры.

Услуги по теме

• Доработка и поддержка сайтаНе каждый проект нужно переписывать. Часто дешевле починить скорость, исправить технические SEO-ошибки, добавить недостающие разделы и интеграции — и получить рабочий сайт без бюджета на новую разработку.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.

Почитать подробнее

• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.
• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.