"Почему мы переписываем legacy 1 в 1 (даже то, что не нравится)" Контекст У нас, как наверное и у всех, есть сервис, который видел мамонтов. Он использует старые библиотеки, живет на железных машинах, и содержать его становится не выгодно, поддерживать больно, а добавлять фичи уже и не имеет смысла. И вот приближаются его последние деньки. Мы решили его переписать! Обычно в таких случаях: 🔹 "А давайте вот эту кнопку перенесем!" 🔹 "А давайте заодно новую фичу добавим!" 🔹 "Вот тут давайте не возвращать эти поля"

Но я принял решение: копируем всё 1 в 1, даже если: ❌ Какие-то части устарели ❌ Где-то криво работает (но работает!) ❌ Есть соблазн сразу "улучшить"

Почему?

Проблема вечного рефакторинга Если сразу править: 1️⃣ Нет чёткого "готово" — когда считать перенос завершённым? 2️⃣ Сроки плывут — каждое улучшение тянет новые правки 3️⃣ Приоритеты теряются — некоторые доработки не имеют большой ценности, но получают повышенный приоритет корневой задачи "переписать сервис"

Итог: 🔄 Бесконечный проект, который никогда не закроется

✅ Моё решение 1️⃣ Сначала — точная копия (даже с костылями) 2️⃣ Фиксируем: "Старое работает? ✅ Новое работает? ✅" 3️⃣ Только потом — улучшения отдельным этапом

Плюсы: ✔ Чёткий показатель успеха— сервис перенесён ✔ Понятное планирование ресурсов ✔ Нет перфекционизма на старте

💡 ИМХО Любой рефакторинг — это компромисс: 🔸 "Идеально" сразу = проект сгорит в доработках 🔸 "Как есть" = контрольная точка для движения вперёд

Вывод: 🚀 Лучше избавиться хотя бы от одной проблемы, чем годами "улучшать"