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

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

1. Посадка на тонущий корабль

Впервые я столкнулся с уродливым легаси кодом больше десяти лет назад. Тогда я только окончил универ и устроился в Amazon на должность «инженера разработки ПО» в команду, отвечавшую за код обработки заказов¹. Снаружи задачи нашего кода выглядели довольно простыми. Для обработки заказа требовалось записывать некоторые данные в БД и вызывать сервисы других команд — для проверки валидности данных или обновления информации на их стороне. Мы с коллегами прикинули, что для уверенной поддержки и развития этого сервиса нам потребуется не более двух десятков хороших разработчиков. Но в нашей организации работали сотни людей, и система разрослась так сильно, что разобраться в её внутреннем устройстве стало невозможно.

В этой организации мало кто задерживается дольше, чем на пару лет, и полноценно сохранить преемственность знаний не удавалось. В итоге код стал переполнен «кладбищами с привидениями»², и страх прикасаться к нему подавлял любые попытки упростить существующие системы (особенно те, которые не сулили достойного вознаграждения). Бизнес-правила, описывающие внутренние механизмы обработки каждого вида заказа, были определены теми, кто уже давно уволился. Иногда описание этих правил можно было отыскать в безнадёжно устаревшем файле с гордым именем «living document», но зачастую они даже не были задокументированы. Да и самостоятельно проследить поведение программы было не легче, так как значительная часть системы находилась в ведении других команд, и прямого доступа к её коду у нас не было.

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

Хотя всё же стоит отдать должное тем отважным сотрудникам, которые не оставляли попыток исправить архитектуру.⁴ Обычно это начинается с того, что новый менеджер или старший разработчик, приходя в компанию, видит, насколько всё паршиво. Руководство согласно и вроде бы желает всё наладить, вот только для этого вечно нет свободных разработчиков, поэтому каждая такая попытка включает расширение штата и формирование новых команд.⁵

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

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

2. Где же реально конец?

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

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

Этот его вопрос и сама метафора тонущего корабля заставили меня задуматься. Немного поразмыслив, я понял, что здесь нужно провести разделение между кодом и компанией.

Бизнес может потонуть, и плохое ПО становится для него реальной обузой. Но степень, до которой эта обуза тянет на дно, зависит от многих факторов. Корпорации с крупными доходами вроде Amazon могут спокойно закрывать глаза на точечные очаги внутреннего загнивания до тех пор, пока это не начнёт ощутимо бить по их прибыли. Для других же компаний, чья бизнес-модель более чувствительна к качеству ПО, ошибки в его создании могут стать скрытым сигналом конкурентам об удачной возможности нанести уязвимому борту критическую пробоину (и LLM тут не спасут⁷).

Если же смотреть с позиции кода, то он может тонуть бесконечно, так как всегда можно сделать ещё хуже. Здесь вы не можете выбежать из здания, которое вот-вот рухнет. Оно находится в перманентном стоянии обрушения. Так что тут не совсем корректно использовать термины, подразумевающие завершённость процесса. 

Да, придирчивый читатель будет прав, если скажет, что в определённый момент ПО может сломаться окончательно. Вот только на практике такие поломки быстро откатываются, чего не скажешь о тысячах губительных изменений, которые им предшествовали. ПО продолжает «работать».⁸ Бывают и другие случаи, когда нельзя найти какой-то один проблемный коммит для отката. В таких сценариях раздутые расходы на обслуживание хромого ПО начинают банально перевешивать его пользу, или же сама разработка встаёт колом, так как уже просто невозможно запустить новую фичу без поломки чего-то рабочего. Во всех этих случаях именно бизнес умирает задолго до того, как код достигнет своего дна (так что не нужно прикидываться, будто это дно есть).

3. Технический долг не сведёшь к банкротству

Кривое ПО является реальной угрозой для бизнеса, и поэтому в предусмотрительных компаниях его качеству уделяют особое внимание. Поскольку нельзя зафиксировать некий порог неудачных решений, после которого система внезапно откажет, зачастую этот феномен называется просто «технический долг». Такое сравнение тоже не идеально, но уже больше подходит в качестве метафоры, так как долги могут копиться бесконечно.

У долга есть своя «конечная» точка, так как итоговое банкротство ведёт к перезапуску с нуля. В программном обеспечении эквивалентом этому будет полное переписывание кода, что редко оказывается приемлемым решением.

Самым близким к этому выходом из положения для таких мегакорпораций, как Amazon будет ответвление, а именно создание специальной команды для построения новой, полностью обособленной системы с минимальным набором функций, необходимых для нового сценария использования. В перспективе по мере продвижения эта команда сможет привязывать к своей упрощённой системе и другие новые фичи. И здесь важно продолжать обслуживать старую систему (это далеко не «конец»), так как прошлые сценарии использования никуда не делись. В итоге для организации возникает новая головная боль всякий раз, когда нужно решить, какую из этих систем использовать под очередную задачу.⁹ Так что это всё ещё не обнуление, которое мы представляем себе при банкротстве.

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

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

Сноски

• Я намеренно не погружаюсь во многие детали этой истории. У меня нет цели повесить вину на отдельных людей или организацию (мы искренне старались исправить ту ситуацию, в которой оказались). Поэтому мой пересказ неполон и служит чисто для общей демонстрации. ↩

• Насколько я знаю, этот термин зародился в инженерной среде Google. Им описывают очень сложные для понимания разделы кода, в которые люди предпочитают даже не заглядывать. ↩

• Для компании было дешевле перекрыть проблему дополнительными серверами, чем серьёзно вкладываться в оптимизацию производительности. Помню в какой-то момент даже довольно мощные машины могли обрабатывать лишь по 1–2 заказа в секунду. Вот только аналогично раздутому штату компании это никак не вязалось с нашей интуицией, которая подсказывала, что мы должны обрабатывать как минимум на два порядка больше. ↩

• Мы с коллегами начали воспринимать эти амбициозные архитектурные цели как какой-то анекдот. Мы иронично называли их «блестящим будущим», наполняя эту фразу сарказмом: «Как только эта $NEXT_ARCHITECTURE приведёт нас в блестящее будущее, проблема исчезнет!» ↩

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

• Если бы я тогда не ушёл, то взял бы под свою ответственность как минимум часть этой новой архитектуры — просто ради дальнейшего повышения. Но вряд ли у меня бы получилось «исправить» ситуацию сильно лучше, чем у остальных. Вся суть в том, что само устройство организации и применяемые в ней механизмы мотивации априори не позволяют создать что-то реально толковое. ↩

• В этой статье я сознательно не развивал тему использования ИИ, так как она устареет быстрее того, о чём я пишу. Но всё же я считаю необходимым затронуть её хотя бы поверхностно. Моё мнение таково: если культура и системы мотивации в вашей компании являются причиной падения качества ПО, то LLM тут уже не помогут. Они только ускорят ваше движение по этой проложенной траектории. Я бы мог развить эту тему, но не хочу отклоняться от основного посыла статьи. Лучше потом напишу отдельную для тех, кому это интересно. ↩

• Проект FizzBuzz Enterprise Edition является своего рода художественным манифестом, в котором этот аспект ПО намеренно доведён до абсурда. ↩

• В Amazon «ответвление» тоже неоднократно происходило, хотя и не с такими темпами, как переделки архитектуры, о которых я поведал в своём рассказе. В мегакорпорациях такое «мягкое выведение из эксплуатации» становится самой вероятной формой отпевания для замучившей всех легаси-системы. В отличие от паттерна «фикус-душитель» (strangler fig), который подразумевает налаживание промежуточного слоя и постепенную замену существующей системы, ответвления намеренно создаются без какого-либо взаимодействия со старой платформой. ↩