Дешёвый код — самый дорогой

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

Это не нравоучение про «делайте правильно». Это экономика. И экономика жёстче, чем думает большинство тех, кто пишет софт.

Стоимость изменения — это кривая, а не число

Вот что почти никто не закладывает в цену: стоимость внесения изменения в софт не постоянна. Добавить одну и ту же фичу в один кодовой базе — дёшево, в другой — разорительно дорого. Разница — архитектура.

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

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

Две команды, один продукт

Мартин Фаулер нарисовал это много лет назад как Design Stamina Hypothesis. Представьте две команды, которые строят один и тот же продукт. Отложите по оси накопленные фичи против времени. Команда, которая пропускает дизайн, впереди в начале — она не «тратит» время на архитектуру. Но линии пересекаются. Фаулер называет точку design payoff line. После неё команда, вложившаяся в дизайн, уходит вперёд и лидерство больше не отдаёт.

Ловушка в том, что ранний отрыв реален и нагляден — его можно задемонстрировать. А точка пересечения невидима, пока ты её сильно не прошёл. К моменту, когда ты чувствуешь, что кривая загибается, ты уже выпустил свой «MVP» на фундаменте, который не держит второй этаж. Ты не сэкономил время. Ты взял его в долг.

Время — это валюта, и счёт огромный

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

• Опрос Developer Coefficient от Stripe: разработчики тратят около 42% недели на технический долг и плохой код — примерно 13,5 часа на поддержку плюс ещё ~4 на возню именно с плохим кодом. Один только плохой код они оценили в $85 миллиардов в год потерянной продуктивности.
• Исследование McKinsey про техдолг перенесло это на баланс: CIO сообщают, что 10–20% бюджета, предназначенного на новые продукты, тихо уходит на обслуживание техдолга (треть из них сказали — больше 20%), а сам техдолг стоит 20–40% всей стоимости их технологического хозяйства. Компании с наименьшим долгом росли по выручке примерно на 20% быстрее тех, кто тащил наибольший.

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

Стена

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

Драматичная версия — Knight Capital: годами в проде болтался мёртвый код, нормальной дисциплины деплоя не было, и однажды утром 2012-го кривой релиз реактивировал код, который давно должен был быть удалён. За 45 минут фирма отправила миллионы непреднамеренных ордеров, потеряла $440 миллионов — и перестала существовать как самостоятельная компания. Большинство команд так эффектно не взрываются. Они делают кое-что тише и, в сумме, дороже: постепенно встают намертво.

А дальше — самый дорогой проект, на который компания может решиться: Большой Переписыватель (Big Rewrite). Переписывают не потому, что старый код уродлив. Переписывают потому, что кривая встала вертикально и другого хода не осталось. Переписывание — не болезнь; это счёт за архитектуру, которую ты не купил, приходящий весь сразу, в худший момент.

«Но быстро — значит жертвовать качеством» — нет

Чаще всего возражают так: архитектура — это налог, который платишь за то, чтобы быть медленным и безопасным, а стартап не может себе этого позволить. Данные говорят ровно обратное. Десять лет исследований DORA (программа Accelerate) находят одно и то же: команды, которые деплоят быстрее всех, имеют и самый низкий процент отказов. Скорость и стабильность — не компромисс, который ты балансируешь, а два следствия одной причины: кодовой базы, которую можно менять уверенно. Хорошая архитектура и есть то, что покупает эту уверенность. Выбор «быстро против качественно» ложный; дешёвые команды просто медленно не получают ни того, ни другого.

Где правила реально двигают рычаг

Вот часть, которая важна на практике. SOLID, DRY, KISS, DI — не академический вкус. Каждое — рычаг на форму той самой кривой:

• Single responsibility (S в SOLID): изменение трогает одно место, а не девять. Радиус поражения каждой правки остаётся маленьким — это разница между «два часа» и «две недели плюс регрессия в checkout».
• DRY — один источник правды на факт: когда правило живёт ровно в одном месте, ты меняешь его один раз. Когда оно скопировано в восьми, ты меняешь восемь раз и забываешь девятое — и девятое и есть тот баг, который уезжает в прод.
• KISS: самое простое, что работает, — самое дешёвое для понимания, а большая часть стоимости софта — не в том, чтобы его писать, а в том, чтобы его читать. Каждая капля твоей сегодняшней «умности» — налог, который платит каждый будущий читатель, включая тебя через полгода, без всякой памяти о том, зачем это было.
• DI — внедрение зависимостей: когда части зависят от контрактов, а не от конкретных реализаций, их можно подменять, тестировать и менять по отдельности. (Я поменял AI-провайдера под этим самым сайтом, изменив одно значение в конфиге, а не переписывая фичу. Это DI покупает плоскую кривую.)

Ни одно из этих правил не про красоту. Все они — про то, чтобы не дать усилиям-на-изменение лезть вверх.

Почему это так трудно продать

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

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

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

«Дёшево» никогда не было дешёвым вариантом.