Cozy_Oksana
New member
Пять лет назад я получил в наследство проект, который работал, приносил деньги и вызывал у команды нервный тик. Кодовая база на древнем фреймворке, сотни скриптов, пара баз данных и ни одного внятного теста. Каждый деплой был похож на русскую рулетку, а слово «рефакторинг» произносилось только шёпотом.
Первым делом я, конечно, загорелся всё переписать. Мы начали делать новый сервис, месяц писали, потом поняли, что не знаем и половины бизнес-правил. В итоге старый монолит продолжал кормить, а новый проект тихо умер в ветке. Тогда я усвоил главное: легаси страшно не потому, что оно плохое, а потому, что оно непонятное и незаменимое. Значит, спасать его нужно не героическим переписыванием, а аккуратным управлением рисками.
Мой план спасения начинается не с кода, а с карты. Я собираю список всех входных точек: веб-страницы, API, очереди, cron, интеграции, ручные скрипты. Дальше фиксирую, какие данные где хранятся, кто и что вызывает, какие отчёты нужны бизнесу. Без этой карты любое изменение — прыжок в темноту. Ещё сразу включаю логирование и метрики там, где их нет. Это дешёвый способ увидеть, как система живёт на самом деле.
Второй шаг — страховка. Я не гонюсь за стопроцентным покрытием тестами. Вместо этого пишу характеристические тесты вокруг критичных сценариев: оплата, регистрация, расчёт заказа, выгрузка. Они фиксируют текущее поведение, даже если оно кривое. Затем настраиваю быстрый откат, бэкапы и флаги функций. Любое изменение должно быть обратимым. Если что-то пошло не так, мы не героически чиним ночь, а возвращаемся к рабочей версии за пять минут.
Третий шаг — стратегия обёртки. Я не трогаю ядро, а строю новый код вокруг старого. Постепенно перевожу отдельные функции: сначала один отчёт, потом уведомления, потом кусок личного кабинета. Старый монолит остаётся как аварийный выход. Такой подход позволяет двигаться месяцами, не останавливая бизнес. Главное — не распыляться и не пытаться вынести всё сразу. Один шов, один сценарий, одна проверка.
Отдельная история — люди и деньги. Бизнесу нужно объяснять, что легаси не сломается завтра, если мы будем действовать осторожно. Но и обещать, что всё будет бесплатно, нельзя. Я всегда прошу небольшой бюджет на технический долг: двадцать процентов времени команды. Это не роскошь, а страховка от внезапной остановки продаж. И ещё важно отмечать маленькие победы: каждый вынесенный модуль, каждый зелёный тест — повод показать прогресс.
Что я рекомендую читателям? Первое: не начинайте с переписывания, начните с наблюдения. Второе: напишите тесты на то, что уже работает. Третье: делайте маленькие обратимые изменения. Четвёртое: автоматизируйте деплой и откат. Пятое: удаляйте то, чем никто не пользуется. Шестое: документируйте не ради галочки, а чтобы через полгода не задавать те же вопросы. И седьмое: не воюйте с легаси, а договаривайтесь с ним.
В итоге я перестал бояться старого проекта. Да, он всё ещё местами страшный, но теперь у меня есть карта, страховка и понятная последовательность шагов. Легаси — это не приговор, а просто система, которая пережила много решений. Если действовать без фанатизма, она может спокойно дожить до пенсии. А у вас был проект, который страшно трогать? Что помогло вам сделать первый безопасный шаг?
Первым делом я, конечно, загорелся всё переписать. Мы начали делать новый сервис, месяц писали, потом поняли, что не знаем и половины бизнес-правил. В итоге старый монолит продолжал кормить, а новый проект тихо умер в ветке. Тогда я усвоил главное: легаси страшно не потому, что оно плохое, а потому, что оно непонятное и незаменимое. Значит, спасать его нужно не героическим переписыванием, а аккуратным управлением рисками.
Мой план спасения начинается не с кода, а с карты. Я собираю список всех входных точек: веб-страницы, API, очереди, cron, интеграции, ручные скрипты. Дальше фиксирую, какие данные где хранятся, кто и что вызывает, какие отчёты нужны бизнесу. Без этой карты любое изменение — прыжок в темноту. Ещё сразу включаю логирование и метрики там, где их нет. Это дешёвый способ увидеть, как система живёт на самом деле.
Второй шаг — страховка. Я не гонюсь за стопроцентным покрытием тестами. Вместо этого пишу характеристические тесты вокруг критичных сценариев: оплата, регистрация, расчёт заказа, выгрузка. Они фиксируют текущее поведение, даже если оно кривое. Затем настраиваю быстрый откат, бэкапы и флаги функций. Любое изменение должно быть обратимым. Если что-то пошло не так, мы не героически чиним ночь, а возвращаемся к рабочей версии за пять минут.
Третий шаг — стратегия обёртки. Я не трогаю ядро, а строю новый код вокруг старого. Постепенно перевожу отдельные функции: сначала один отчёт, потом уведомления, потом кусок личного кабинета. Старый монолит остаётся как аварийный выход. Такой подход позволяет двигаться месяцами, не останавливая бизнес. Главное — не распыляться и не пытаться вынести всё сразу. Один шов, один сценарий, одна проверка.
Отдельная история — люди и деньги. Бизнесу нужно объяснять, что легаси не сломается завтра, если мы будем действовать осторожно. Но и обещать, что всё будет бесплатно, нельзя. Я всегда прошу небольшой бюджет на технический долг: двадцать процентов времени команды. Это не роскошь, а страховка от внезапной остановки продаж. И ещё важно отмечать маленькие победы: каждый вынесенный модуль, каждый зелёный тест — повод показать прогресс.
Что я рекомендую читателям? Первое: не начинайте с переписывания, начните с наблюдения. Второе: напишите тесты на то, что уже работает. Третье: делайте маленькие обратимые изменения. Четвёртое: автоматизируйте деплой и откат. Пятое: удаляйте то, чем никто не пользуется. Шестое: документируйте не ради галочки, а чтобы через полгода не задавать те же вопросы. И седьмое: не воюйте с легаси, а договаривайтесь с ним.
В итоге я перестал бояться старого проекта. Да, он всё ещё местами страшный, но теперь у меня есть карта, страховка и понятная последовательность шагов. Легаси — это не приговор, а просто система, которая пережила много решений. Если действовать без фанатизма, она может спокойно дожить до пенсии. А у вас был проект, который страшно трогать? Что помогло вам сделать первый безопасный шаг?