Что такое рефакторинг на практике
Представьте склад, где нужные вещи есть, но лежат в случайных местах. Каждый заказ собирается дольше, а при перестановке легко что-то потерять. Рефакторинг — работа над порядком внутри системы: разделить обязанности, убрать запутанные связи и сделать правила понятнее.
Для пользователя привычный сценарий может остаться прежним. Для разработчика становится проще найти нужное место и изменить его без цепочки неожиданных поломок. Это снижает трудоёмкость следующих изменений там, где причина действительно была в устройстве кода.
Рефакторинг стоит отличать от исправления ошибки и добавления возможности. Если расчёт неверный — исправляем поведение. Если нужен новый отчёт — расширяем продукт. Если одинаковый расчёт разнесён по пяти местам и его трудно менять — приводим устройство кода в порядок.
Признаки, что поддержка стала слишком дорогой
- Одинаковые правила реализованы в нескольких местах и дают разные результаты.
- Небольшая правка требует менять много несвязанных на первый взгляд файлов.
- Никто не уверен, какие сценарии сломаются после обновления.
- Ошибки исправляются повторно, потому что устраняется проявление, а не причина.
- Знание проекта сосредоточено у одного человека, а код и документация мало помогают остальным.
Старый проект не обязан быть плохим. Если он стабилен, выполняет задачи и доступен для поддержки, масштабная переделка может не окупиться. Сначала выясняем, что именно мешает бизнесу.
Как навожу порядок без бесконечной переделки
Разбираю состояние
Любая работа с чужим кодом начинается с аудита. Выбираем важные сценарии, подтверждаем проблемы и оцениваем риски изменений.
Фиксирую нужное поведение
Проверки и примеры показывают, как система должна работать. Это помогает отличить сохранение бизнес-правила от случайного сохранения старой ошибки.
Меняю небольшими этапами
Согласуем приоритетные участки и результат каждого этапа. Изменения можно проверять по отдельности и сопоставлять с ожидаемой пользой.
Оставляю понятный результат
Фиксирую, что изменилось, как проверялось и какие ограничения остались. Следующий шаг должен быть понятен без повторного исследования всего проекта.
Пример: одно правило в разных частях системы
Как устроена поддержка после запуска
После запуска в течение 6 месяцев поддерживаю проект и исправляю баги в согласованном функционале за свой счёт. Чтобы было ясно, что считать ошибкой, до разработки фиксируем ожидаемое поведение и критерии готовности.
Если результат соответствует ТЗ, но вы хотите другой интерфейс, новый расчёт или дополнительную интеграцию, это изменение требований — Change Request. Его объём и стоимость согласуем отдельно до реализации.
Объём дальнейшего развития, дополнительные задачи и условия постоянной поддержки обсуждаются по состоянию проекта. Само слово «поддержка» не заменяет договорённость о конкретной работе.
Как удержать работу в понятных границах
Цель этапа должна быть проверяемой: например, устранить расхождения в расчёте или упростить добавление нового способа доставки. «Сделать весь код идеальным» не даёт ни границы бюджета, ни понятного момента завершения.
Для проекта можно согласовать полную стоимость. Для небольшой работы — часовую ставку и заранее оговорённое количество часов. Новые находки сначала обсуждаем: они могут изменить приоритеты, но не должны превращаться в неожиданный счёт.
Для начала расскажите, какая доработка сейчас даётся тяжелее всего, какие ошибки повторяются и что системе нужно уметь дальше.
ЕЩЁ НЕСКОЛЬКО ОТВЕТОВ
Что важно уточнить
Придётся полностью переписать проект?
Это не исходное условие. После аудита сравним варианты: точечные исправления, постепенные изменения или замена отдельных частей. Решение зависит от состояния системы, рисков и задач бизнеса.
Вы работаете с тяжёлым старым кодом?
Да. Не боюсь сложного и неподдерживаемого кода. Но сначала провожу аудит и оцениваю последствия изменений.
Можно вместе с рефакторингом добавить новую функцию?
Можно согласовать обе задачи. Важно разделить ожидаемые результаты и стоимость, чтобы изменение поведения не скрывалось под словом «рефакторинг».