Работа со старым кодом для многих команд является частью повседневных обязанностей. За свою карьеру я видел и применял разные способы борьбы с тяжестью легаси. Они обычно сводились к одному из трёх основных сценариев:
«Работает — не трогай!»: вообще забить на чистки и ничего не менять. В некоторых случаях валидный подход. Но в коде, который приходится менять хотя бы даже эпизодически (фиксы багов, мелкие доделки, смена окружения и т. п.), со временем неизбежно приводит к катастрофе. Вам надо что‑то поменять в коде, и это оказывается невозможно сделать легко. Даже за тривиальные изменения приходится платить большой кровью.
«Я прочитал Роберта Мартина»: включаем чистки в обычный код. Надеваем галстук бойскаута и чистим код прямо по ходу работы над текущими задачами. Отправляем его коллегам на ревью и ждём несколько дней, покуда они не разберутся, где заканчиваются рефакторинги и начинаются непосредственно изменения по задаче. Или же уходим по кривой дорожке рефакторингов в тёмный лес и продалбываем к чертям все изначальные сроки. Когда начинаешь приводить код к идеалу, не всегда бывает так легко остановиться!
«Нужен порядок и учёт»: делаем отдельные коммиты с чистками, но нерегулярно — только когда в дело берётся соответствующий тикет. Правда, тикеты на рефакторинг почему‑то регулярно получают самый низкий приоритет во время планирования и маринуются в беклоге месяцами. Но что уж тут поделать?
Это всё ловушки! Все эти сценарии страдают одной общей проблемой: темп чисток неудовлетворительно низок. Код зарастает грязью и происходит неизбежная деградация. Задачи делаются всё медленнее, процент дефектов всё выше, отвращение от работы с кодом растёт, новички адаптируются всё медленнее и медленнее. Все несчастны и не знают, что делать.
За прошедший год я нащупал и отточил ещё один подход, который лишён указанных недостатков. И теперь готов поделиться им с вами.
