Модернизация устаревшего ПО без полного переписывания с нуля

Почти у каждой устоявшейся компании есть такое: фрагмент ПО, который все тихо ненавидят. Он медленный, уродливый, половина команды знает обходной путь для бага, который так и не починили, а единственный человек, понимавший его, ушёл в 2019 году. Порыв всегда один и тот же — снести всё и построить заново. И именно этот порыв чаще всего и есть тот способ, которым хорошие компании теряют год и небольшое состояние впустую.

Я видел, как большое переписывание идёт не так, достаточно часто, чтобы выработать на это рефлекс. Основатель показывает мне свою скрипучую систему заказов или древний инструмент для составления графиков, вздыхает и говорит какую-то версию фразы «нам просто нужно заменить всё целиком». И, возможно, однажды так и будет. Но полное переписывание — вырвать старую систему, построить рядом блестящую новую, а потом щёлкнуть выключателем — один из самых рискованных шагов во всей сфере ПО. Он дорогой, занимает гораздо дольше обещанного, и всё это время вы летите вслепую, надеясь, что новое покроет каждый странный краевой случай, который старое тихо обрабатывало пятнадцать лет.

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

Почему полное переписывание так соблазнительно — и так опасно

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

Более глубокая ловушка — проблема параллельной вселенной. На те месяцы или годы, что строится замена, у вас две системы: старая, которой всё ещё нужно вести бизнес, и новая, которая пока не готова. Каждое изменение, нужное бизнесу, приходится вносить дважды, иначе новая система отстаёт от реальности ещё до запуска. Команды выгорают, поддерживая обе. А поскольку никому нельзя переключиться, пока новая система не делает всё, нет ни ранней победы, ни обратной связи, ни доказательства, что это работает, — лишь долгое тревожное ожидание одного огромного дня запуска по принципу «всё или ничего».

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

Что на самом деле значит «legacy» (дело не в возрасте)

Мы бросаемся словом legacy, будто оно просто значит «старое». Это не так. Множество ПО, работающего десятилетие, совершенно в порядке — скучное, стабильное, оплаченное, делает своё дело. Один лишь возраст не повод что-либо трогать. Самая дорогая ошибка во всей этой области — модернизировать то, что тихо работало, лишь потому, что оно выглядело устаревшим.

ПО заслуживает ярлыка legacy, когда оно активно мешает вам. Когда его нельзя безопасно изменить, потому что никто не понимает его полностью. Когда оно не может подключиться к инструментам, от которых вы теперь зависите. Когда один человек — единственный, кто способен поддерживать его в живых. Когда оно настолько медленное или хрупкое, что команда выстроила вокруг него целый фольклор обходных путей. Вот настоящее определение — не год написания, а та цена, которую оно навязывает вам сегодня, и тот риск, что оно несёт в завтра.

Поставьте диагноз, прежде чем что-либо трогать

Прежде чем перепишется хоть одна строка, вам нужна честная карта того, где боль действительно живёт. Чаще всего система, которую все ненавидят, на 80% в порядке. Беда сосредоточена в нескольких конкретных местах — один медленный экран, одна сломанная интеграция, один процесс, заставляющий вводить данные дважды, — и эти несколько мест порождают почти все жалобы. Найдите их — и вы нашли весь свой проект.

Способ их найти — не технический аудит в первую очередь, а разговор. Сядьте с людьми, которые пользуются этим каждый день, и спросите, где болит. Где они ждут? Что перепечатывают? Чего избегают, потому что это мучительно? Где ведут личную таблицу, чтобы обойти официальную систему? Эти обходные пути — золото: каждый из них точный рентген проблемы, которую стоит чинить.

• Экраны и шаги, на которые люди жалуются больше всего — не в теории, а в их реальной ежедневной работе.
• Каждое место, где данные вводятся дважды, потому что две системы не разговаривают друг с другом.
• Интеграции, которые сломались или никогда не существовали, вынуждая вручную копировать-вставлять между инструментами.
• Всё, что умеет обслуживать или чинить лишь один человек — ваши единые точки отказа.
• Части, которые по-настоящему в порядке, чтобы вы могли защитить их и оставить как есть.
• То, что понадобится бизнесу в следующем году и во что нынешняя система просто не способна вырасти.

Когда вы делаете это честно, проект обычно сжимается. Владелец, вошедший со словами «заменить всё», выходит с пониманием, что ему нужно починить три вещи. Это не разочарование — это облегчение. Три починяемые вещи — проект, который вы закончите в этом квартале. Полная замена — год, который вы, возможно, не переживёте.

Подход strangler: заменяйте по одной части за раз

Есть паттерн делать это безопасно, и у него слегка мрачное, но запоминающееся имя: подход strangler, по фикусу-душителю — лиане, которая растёт вокруг дерева, постепенно перенимая его структуру, пока в итоге новый рост не встанет сам по себе, а старый ствол не исчезнет. Применительно к ПО идея прекрасно практична: вы не заменяете старую систему одним героическим обменом. Вы выращиваете новую вокруг неё, по части за раз, пока от старой не останется ничего, что кому-то нужно.

На практике это работает так. Вы выбираете одну болезненную часть — скажем, модуль выставления счетов, который все ненавидят. Вы строите современную замену только для этой части. Вы направляете выставление счетов в новый модуль, пока всё остальное продолжает работать на старой системе, нетронутым. Вы наблюдаете за этим какое-то время. Когда он надёжен, эта часть старой системы затихает, и вы переходите к следующей части. Старая система сжимается постепенно, как свеча, вместо того чтобы быть снесённой разом.

Что делает это настолько безопаснее переписывания — то, что каждый шаг мал, в живой работе и обратим. Вы никогда не летите вслепую. Каждая новая часть быстро идёт в реальное использование, поэтому вы быстро узнаёте, работает ли она на самом деле. Если что-то идёт не так, вы рисковали лишь одним модулем, а не всем бизнесом — и обычно можете откатиться на старый путь, пока чините. Вы получаете победы по дороге вместо одного ужасающего запуска в конце. И бизнес всё это время работает как обычно.

Как этот ритм выглядит на деле

1. 1
   Выберите самую болезненную, самую самодостаточную часть

   Вам нужна высокая боль и чистые края — модуль, который сильно болит и не запускает пальцы во всё остальное. Это ваша первая цель.
2. 2
   Поставьте тонкий слой перед старой системой

   Небольшой слой маршрутизации решает, какие запросы идут в старую систему, а какие — в новую часть. Это тот шов, который делает всё остальное возможным.
3. 3
   Постройте и запустите только эту одну часть

   Замените один модуль, отдайте его в реальные руки и направьте в него лишь этот срез работы. Недели, а не годы — и остальная система даже не сдвинулась.
4. 4
   Стабилизируйте, затем переходите к следующей части

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

   В итоге устаревшая система не делает ничего, на что кто-либо опирается. Лишь тогда вы её выключаете — тихо, без драмы, потому что всё важное уже переехало.

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

Иногда её даже не нужно заменять

Прежде чем вообще что-то заменять, стоит спросить, нужна ли старой системе замена или ей просто нужно перестать быть островом. Удивительно много проблем вида «нам нужна новая система» на деле — проблемы «наши системы не разговаривают друг с другом». Старое ПО в порядке со своей работой — оно просто сидит в силосе, заставляя людей вручную переносить данные туда-сюда.

В таких случаях самая дешёвая и быстрая починка — не новая система. Это мост. Вы оборачиваете старое ПО соединением — интеграцией, которая позволяет ему автоматически обмениваться данными с другими вашими инструментами, — и современным слоем сверху для тех частей, которых люди действительно касаются. Устаревший движок продолжает гудеть внизу; команда получает чистую поверхность и конец копированию-вставке. Это не эффектно, но часто даёт наивысшую отдачу на каждое евро во всём начинании.

Когда полное переписывание действительно оправдано

Я всё это руководство отговаривал вас от большого переписывания, так что буду честен: иногда оно и правда ответ. Бывают фундаменты настолько гнилые, что никакое количество заплаток, мостов или замены по частям их не спасёт, и притворяться иначе значит лишь оттягивать неизбежное, тратя деньги на подпорку трупа.

Честные признаки конкретны. Технология, на которой построена система, мертва или умирает — нет поддержки, нет обновлений безопасности, не осталось никого, кто мог бы с ней работать. Бизнес изменился настолько фундаментально, что старая модель вообще больше не отображает реальность. Или система так запутана, что даже мелкие изменения регулярно ломают вещи в несвязанных местах, а это обычно значит, что чистых швов для подхода strangler нет в принципе. Когда две-три из этих вещей верны одновременно, поэтапная работа перестаёт быть более безопасным выбором.

И вот тихая награда за то, что сначала сделана поэтапная работа, даже если вы в итоге всё же перестроите систему: к тому времени, как вы туда доберётесь, вы будете понимать систему куда лучше, чем в начале. Каждый заменённый модуль научил вас тому, что исходные авторы так и не записали. Переписывание, питаемое этим знанием, — совершенно иной, куда более безопасный зверь, чем то, что запущено на оптимизме первого дня.

Часть, о которой никто не упоминает: дело в основном в людях

Вот то, что технические руководства пропускают. Самое трудное в модернизации старого ПО обычно не код — это люди, которые годами под него подстраивались. Они знают его причуды. У них мышечная память на его странные сочетания клавиш. Новый модуль, объективно лучший, первые две недели всё равно может ощущаться хуже — просто потому, что он незнаком. Если вы это проигнорируете, даже идеальная техническая миграция может провалиться.

Поэтапный подход помогает и здесь, почти невзначай. Поскольку изменение приходит по одной маленькой части за раз, люди впитывают его постепенно, а не получают задачу переучить всё за одно утро понедельника. Вовлекайте ежедневных пользователей рано. Дайте им формировать замену, пока она не закончена. Команда, помогавшая спроектировать новый экран счетов, будет его защищать; команда, которой его свалили на голову, будет его ненавидеть, даже если он идентичен. Модернизация — это проект управления изменениями в костюме ПО.

Частые вопросы