Legacy-код: чинить, переписывать или жить с ним

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

Решение стоит принимать по расчёту, а не по впечатлению.

Что обычно скрывается за «всё плохо»

Стоит разделять четыре разных диагноза — лечатся они по-разному.

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

Отсутствие документации. Никто не знает, как это работает. Лечится изучением и записыванием — неприятно, но дешевле переписывания.

Плохая архитектура. Всё связано со всем, изменение в одном месте ломает в другом. Настоящая проблема, но её можно лечить частями.

Дыры в безопасности. Единственный случай, требующий немедленных действий независимо от выбранной стратегии.

Три стратегии

Жить с этим

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

Но даже здесь минимум обязателен: обновления безопасности, работающие резервные копии, доступ к коду у вас, а не только у автора.

Дорабатывать

Подходит в большинстве случаев. Новое пишется по-человечески, старое трогается только там, где приходится, и постепенно приводится в порядок.

Работает при одном условии: должно быть правило «трогаешь участок — приводишь в порядок». Без него доработка превращается в наслоение нового поверх старого, и через год становится хуже, чем было.

Переписывать

Оправдано в трёх случаях:

• технология снята с поддержки настолько, что её невозможно развернуть на современном сервере;
• стоимость каждой доработки выросла втрое-впятеро против нормальной, и это измерено, а не почувствовано;
• система не выдерживает нагрузку, и причина в архитектуре, а не в настройках.

Почему переписывание чаще проваливается

Причины повторяются от проекта к проекту.

Недооценка объёма. В старой системе за годы накопились сотни мелких правил, о которых никто не помнит. Каждое было ответом на реальную ситуацию. При переписывании они теряются и всплывают жалобами пользователей по одной.

Заморозка развития. Пока пишется новая версия, старая не развивается. Полгода-год без изменений — серьёзная цена, а сроки переписывания обычно превышают план вдвое.

Момент переключения. Перевести всех пользователей на новую систему за один день почти невозможно, а параллельная работа двух систем — отдельная сложная задача.

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

Постепенная замена

Компромисс, который на длинных проектах работает лучше обеих крайностей. Новая система строится рядом со старой и по частям перехватывает её работу.

Например: старый сайт остаётся, но раздел каталога начинает обслуживать новое приложение. Затем личный кабинет. Затем оформление заказа. Пользователь ничего не замечает, а старая система постепенно пустеет и однажды выключается.

Дольше и требует аккуратности на стыках. Взамен: система работает всё время, каждый этап даёт результат, а остановиться можно на любом шаге.

С чего начать в любом случае

С аудита. Внешняя команда изучает код и инфраструктуру и отвечает на конкретные вопросы: что с безопасностью, что с зависимостями, где узкие места, сколько стоит привести в порядок, сколько — переписать.

Стоит 40–120 тысяч и занимает 1–2 недели. По сравнению с ценой ошибочного решения — недорогая страховка. Заказывать его лучше не у того, кто потом будет переписывать: у автора рекомендации не должно быть интереса в её выводе.