Сегодня хотел бы поднять тему Legacy. Но не про то Legacy, которое человек получает по наследству от богатого родственника, а про другое, с которым мы часто сталкиваемся в ИТ, и которое имеет негативную коннотацию.
Всё началось с того, что я наткнулся на текст Patterns of Legacy Displacement. С одной стороны, это статья, в которой в общих чертах и с разных сторон рассматриваются проблемы модернизации Legacy-решений. С другой стороны - это подборка вполне конкретных шаблонов модернизации, ссылки на описание которых приводятся по мере повествования. Авторы заверяют, что будут развивать и поддерживать этот материал в актуальном состоянии, поэтому ссылки на некоторые шаблоны, к сожалению, отсутствуют. В целом, рекомендую для ознакомления или добавления в закладки.
Между тем, хотелось бы определиться, что такое Legacy. Сталкиваясь с этим, в зависимости от ситуации могут возникать двоякие ощущения: страх или жажда всё переписать и сделать нечто совершенное. Первое, как правило, связано с боязнью нарушить работоспособность существующего решения; второе — с моральной усталостью его поддержки. И если нам предоставляется шанс пойти по пути модернизации, то вспомните, с каким опьяняющим азартом мы начинаем махать шашкой и развешивать ярлыки на авторов модернизируемого решения. Кого интересует предыстория?! Нам дали шанс уничтожить ненавистного врага! Знакомо? Получилось добиться желаемого успеха и прийти к желаемому совершенству?
Прежде чем начинать модернизацию, нужно сделать шаг назад и ответить на вопрос, почему Legacy стал Legacy. Накопился слишком большой технический долг? Или дело в (устаревшем) технологическом стеке? Или просто не осталось специалистов, у которых есть нужные компетенции для поддержки? Конечно, это далеко не полный перечень вопросов, но их цель, я думаю, ясна: не повторить прошлый опыт.
Посмею сделать небольшую ремарку. Я не могу согласиться с тем, что (устаревший) технологический стек может являться основной причиной получения метки "Legacy". Только если это приводит к серьезным временным/финансовым издержкам/рискам или обусловлено внешним фактором (например, импортозамещением). В остальных случаях это не Legacy. Даже на самой замшелой технологии и древнем языке код может быть написан аккуратно, выглядеть структурно и понятно и не иметь значимых технических долгов. Называя такой проект Legacy, мы просто выражаем своё нежелание работать с ним или указываем на трудность найма специалистов для его поддержки. Проект становится Legacy, когда он серьезно затрудняет развитие бизнеса. Только это может являться поводом внесения значительных изменений, модернизации или замены существующего решения.
Апеллируя к своему большому опыту, авторы вышеуказанного текста заключают, что корень проблемы появления Legacy находится всё-таки на уровне культуры организации, её структуры и принятых методов. Таким образом указывают на прямую связь с законом Конвея. То есть после того, как мы сделали ретроспективу и выявили причины прошлых неудач, нужно постараться разорвать порочный круг, определив не только цель предстоящих изменений, но и сделав необходимые организационные изменения.
Вместе с этим отмечается, что нельзя рассматривать инициативу по замене Legacy в отрыве от текущих бизнес-целей. Иначе говоря, если вести разработку как обычно (Business As Usual), а замену Legacy рассматривать как параллельную инициативу без поправок на реалии, ничего не выйдет. В лучшем случае получится то же самое, в худшем — "новая версия", которая слишком сильно или ненужным образом будет отличаться от реалий и желаемого результата. Выражаясь техническим языком, не нужно делать долгоживущие fork-и проекта, они будут слишком сильно оторваны от целей.
Авторы также указали на острую необходимость декомпозиции. И тут я с ними полностью согласен. Большой и сложный проект крайне трудно заменить целиком. Любые попытки сделать это часто обречены на полный провал либо на появление еще одной, но новой неуклюжей системы, которая будет жить вечно рядом со старой. Чаще всего можно наблюдать второй вариант, так как бизнес всё равно будет требовать результатов и вывода новой разработки в промышленную эксплуатацию.
***
Как думаете, помогут ли подобные советы не довести проект до состояния Legacy или сделать успешную замену такого решения? Делитесь своим (или не своим) успешным и неуспешным опытом.
P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. ;-)