Как переписывать Легаси

Написал мне читатель с насущным вопросом. Их команда планирует переписывать свой интернет-магазин. Сейчас там бурлят горячие споры: какой подход выбрать, как это все проектировать. У автора вопроса одно мнение, у его коллег - другое. Например, автор, как я понимаю, предлагает заранее разметить bounded contexts, а его коллеги хотят использовать гексагональную архитектуру, медиаторы, cqrs, command pattern и иные подходы.

Читая этот вопрос, я увидел сразу несколько больных точек, которые хотел бы прокомментировать на широкую аудиторию. С согласия автора вопроса, конечно.

1. Big Bang Replacement

Судя по тому, куда пошла дискуссия у коллег, вижу, что они всерьёз рассматривают написать новую систему взамен старой. И я хочу от этого предостеречь: как сказал однажды Мартин Фаулер, вместо big bang replacement чаще всего получается просто big bang. Обычно, легаси содержит так много функционала, что весь его перенести в обозримые сроки не представляется возможным. Он даже, как правило, нормально не задокументирован, поэтому никто в реальности не в курсе, сколько всего там система делает. В то же время, новая система чаще всего получается очень сырой. Поэтому такой опыт замены выходит, как правило, весьма негативным.

Так что рекомендую использовать один из двух подходов: либо долго и аккуратно рефачить текущую легаси до состояния не-легаси, либо использовать паттерн Strangler Fig (фикус-душитель, см фото). Последний - это подход, когда вы не заменяете существующую систему целиком, а постепенно переносите функционал из старой системы в новую. При этом начинать стоит именно с корневого функционала, чтобы не тащить в новую систему легаси-подходы. Так стоит делать, когда легаси нормально отрефачить не представляется возможным.

2. Big upfront design

Big bang replacement подразумевает big upfront design. И это тоже плохо работающий подход. Ни ИИ, ни человек не способны охватить умом все поведение, все нюансы и детали полноценной enterprise-системы. И, когда вылезает очередной "сюрприз", приходится из соплей и палок городить костыль, чтобы воткнуть внезапную находку в заранее продуманную "красивую" архитектуру. По итогу, вместо заранее продуманной красивой архитектуры получается нагромождение костылей.

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

При этом bounded contexts, медиаторы, cqrs, command pattern - это всё шаблоны для решения конкретных проблем. Их надо тащить не сразу на раннем этапе проектирования, они должны применяться по месту на этапе разработки конкретного функционала.

И из вышеперечисленного списка выделяется только гексагональная архитектура, потому что это именно то, что стоит применять с самого первого дня: это сильный буст в decoupling, cohesion, separation of concerns и testability. Простите мне мой алабамский акцент.

3. Социальный фактор

А вот это отменяет вообще все те советы, что я упомянул выше. Почему? Потому что, если с вами не согласны, то хрен вы что с этим сделаете. Можно по какому-то вопросу подвинуть позицию человека, но радикально - скорее всего, ничего не выйдет.

Если вы разраб, то, боюсь, придётся очень сильно подвинуться и смириться с тем, что все будет сделано не как надо, а как получится.

Если вы тимлид, то у вас есть опция навязать решение, но не рекомендую. Если заставлять человека делать то, что ему не нравится, то это может закончиться тем, что он намылит лыжи и сделает вам ручкой. Может показаться, что сейчас рынок работодателя, что найдёте нового. Но это не так. Сейчас рынок никого: соискатель не может найти нормальную работу, именно потому что работодатель не может нанять никого взамен - почти везде найм либо заморожен, либо сильно ограничен.

В нашей команде все решения по дизайну принимает разработчик - сам пишет, сам отвечает за свои решения.