Переписывать ли легаси? Один из вопросов из зала на конференции звучал примерно так: «стоит ли сразу и полностью переписывать легаси?» Часто легаси воспринимается как мусор, помойка. Но при этом в легаси живут тонны накопленного неявного знания, например: ▪️Обходные пути в реализации редких сценариев ▪️Исторически сложившиеся ограничения ▪️Древние договоренности ▪️Порой совершенно неочевидные интеграции ▪️Точечные решения на основе поведения пользователей ▪️Ошибки, которые когда-то были исправлены, возможно без обратного внесения в документацию, просто было «по пути» Без восстановления знания о легаси в худшем случае все неявное знание может быть утеряно. Суть в том, что проектируя идеальное решение в текущем представлении можно потерять то, что сделало решение немного уродливым, но рабочим и успешным. Однако разве не является как раз рабочее и успешное решение идеальным? Нет. Работающее и успешное решение – идеально относительно требований сегодняшнего дня, а система живет во времени. У нее есть и другое измерение качества – стоимость будущих изменений. Если каждая новая фича стоит три месяца и один инцидент, если единственный человек, понимающий модуль тарификации, уволился в позапрошлом году, если под этим всем лежит рантайм без обновлений безопасности, то… решение работает, но уже не успешно, просто счет приходит с задержкой, но приходит. Отвечая на вопрос в заголовке, «все и сразу» переписывать не стоит почти никогда. Постепенное вытеснение (strangler fig) дает ценность частями и сохраняет возможность остановиться на полпути (что, однако, будет стоить поддержки двух систем одновременно), если приоритеты изменились. «Все и сразу» выплачивает все в конце, при этом старая система продолжает жить и обрастать фичами, и переписывание пытается нагнать это развитие, сюда же момент переключения – это единственная точка, где вся накопленная неопределенность реализуется одновременно. «Все и сразу» применимо в достаточно ограниченном спектре ситуаций: платформа умерла (вендор ушел) и постепенная миграция по этой причине физически не может быть осуществлена. ▪️Система достаточно мала, чтобы написать ее заново было дешевле, чем провести детальный анализ ▪️Предметная область кардинально изменилась, и старое поведение более не актуально в принципе Как же восстанавливать неявное знание? ▪️Исследование предметной области (DDD, Event Storming, …) ▪️Анализ истории изменений в связке с задачами в таск-трекере ▪️Анализ задач в таск-трекере в исторической перспективе, включая комментарии ▪️Анализ логов и трафика ▪️Анализ артефактов эксплуатации ▪️Анализ данных в прод базе ▪️Тесты, фиксирующие поведение AS IS ▪️Анализ требований и внешних спецификаций (законы, приказы, ..) ▪️Интервью саппорта ▪️Shadowing (прогон реального трафика через обе системы со сравнением ответов) И в заключении еще один важный момент. Не все выявленное знание __все еще истинно__. После восстановления важно посмотреть на полученную картину критически и отбросить то, что уже не актуально как в части бизнес-процессов, так и в части технической реализации, иначе есть риск в новую систему перенести за компанию и внушительную часть технического долга.