# Дешёвый код — самый дорогой Стоимость изменения софта не постоянна — она идёт по кривой, и форму этой кривой задаёт архитектура. Сэкономить на SOLID, DRY, KISS и DI нельзя — счёт просто переносится на потом, с процентами. Разбираю экономику, с цифрами. - **Author:** Фёдор Чищин - **Published:** 2026-06-02 - **Tags:** architecture, methodology, business - **Source:** https://fedorthinks.com/ru/blog/cheap-code-is-expensive --- Я видел этот фильм не один раз. Команда решает шипить быстро и пропустить архитектуру — «давай по-быстрому накидаем, так дешевле, потом докрутим». Первый месяц — летят. Фичи выкатываются каждый день, все друг друга поздравляют. Девятый месяц — той же команде нужно три недели, чтобы поменять кнопку, любая оценка ошибается втрое, и payment-код никто не трогает, потому что в прошлый раз из-за него лёг checkout. «Дешёвая» версия оказалась дорогой. Это не нравоучение про «делайте правильно». Это экономика. И экономика жёстче, чем думает большинство тех, кто пишет софт. ## Стоимость изменения — это кривая, а не число Вот что почти никто не закладывает в цену: **стоимость внесения изменения в софт не постоянна.** Добавить одну и ту же фичу в один кодовой базе — дёшево, в другой — разорительно дорого. Разница — архитектура. Это не мнение, это наблюдаемый закон. В 1970-х Меир Леман изучал, как большие системы эволюционируют десятилетиями, и один из его [законов эволюции ПО](https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution) — _нарастающая сложность_: по мере развития системы её сложность растёт, **если не прикладывать отдельных усилий, чтобы её снижать.** Каждое изменение добавляет немного беспорядка. Следующему изменению приходится сквозь этот беспорядок продираться — значит, оно стоит чуть дороже. Потом оно добавляет свой беспорядок. Стоимость одного изменения ползёт вверх. Вот эта кривая: усилия-на-фичу против времени. Хорошая архитектура не делает изменения бесплатными — она держит кривую плоской. Плохая — отпускает её в экспоненту. ## Две команды, один продукт Мартин Фаулер нарисовал это много лет назад как [Design Stamina Hypothesis](https://martinfowler.com/bliki/DesignStaminaHypothesis.html). Представьте две команды, которые строят один и тот же продукт. Отложите по оси накопленные фичи против времени. Команда, которая пропускает дизайн, **впереди в начале** — она не «тратит» время на архитектуру. Но линии пересекаются. Фаулер называет точку _design payoff line_. После неё команда, вложившаяся в дизайн, уходит вперёд и лидерство больше не отдаёт. Ловушка в том, что ранний отрыв реален и нагляден — его можно задемонстрировать. А точка пересечения невидима, пока ты её сильно не прошёл. К моменту, когда ты чувствуешь, что кривая загибается, ты уже выпустил свой «MVP» на фундаменте, который не держит второй этаж. Ты не сэкономил время. Ты взял его в долг. ## Время — это валюта, и счёт огромный Каждый час, который разработчик тратит на борьбу с кодовой базой вместо работы внутри неё, — это деньги. И таких часов _очень_ много. - Опрос [Developer Coefficient](https://stripe.com/files/reports/the-developer-coefficient.pdf) от Stripe: разработчики тратят около **42% недели** на технический долг и плохой код — примерно 13,5 часа на поддержку плюс ещё ~4 на возню именно с плохим кодом. Один только плохой код они оценили в **$85 миллиардов в год** потерянной продуктивности. - Исследование [McKinsey про техдолг](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity) перенесло это на баланс: CIO сообщают, что **10–20% бюджета, предназначенного на новые продукты**, тихо уходит на обслуживание техдолга (треть из них сказали — больше 20%), а сам техдолг стоит **20–40% всей стоимости их технологического хозяйства.** Компании с _наименьшим_ долгом росли по выручке примерно на **20% быстрее** тех, кто тащил наибольший. Прочитайте эти цифры одной фразой: **строить дёшево — не значит убрать затрату, значит перенести её.** Ты убираешь её из бюджета на разработку — видимого, разового, того самого, который пытался ужать, — и кладёшь в бюджет на поддержку, который невидим, бесконечен и накапливается. Ты поменял покупку на подписку и не прочитал условия продления. ## Стена Кривая не просто становится крутой. В какой-то момент она встаёт вертикально. Наступает точка, где добавить фичу так долго или так ломающе, что ты фактически _не можешь_ — продукт перестаёт быть способным развиваться. А конкурент, который держал свою кривую плоской, спокойно проходит мимо, добавляя то, что твои же клиенты просят у тебя. Драматичная версия — [Knight Capital](https://www.henricodolfing.ch/en/case-study-4-the-440-million-software-error-at-knight-capital/): годами в проде болтался мёртвый код, нормальной дисциплины деплоя не было, и однажды утром 2012-го кривой релиз реактивировал код, который давно должен был быть удалён. За **45 минут** фирма отправила миллионы непреднамеренных ордеров, потеряла **$440 миллионов** — и перестала существовать как самостоятельная компания. Большинство команд так эффектно не взрываются. Они делают кое-что тише и, в сумме, дороже: постепенно встают намертво. А дальше — самый дорогой проект, на который компания может решиться: Большой Переписыватель (Big Rewrite). Переписывают не потому, что старый код уродлив. Переписывают потому, что кривая встала вертикально и другого хода не осталось. Переписывание — не болезнь; это счёт за архитектуру, которую ты не купил, приходящий весь сразу, в худший момент. ## «Но быстро — значит жертвовать качеством» — нет Чаще всего возражают так: архитектура — это налог, который платишь за то, чтобы быть медленным и безопасным, а стартап не может себе этого позволить. Данные говорят ровно обратное. Десять лет [исследований DORA](https://www.multitudes.com/blog/dora-metrics) (программа _Accelerate_) находят одно и то же: команды, которые деплоят **быстрее всех**, имеют и **самый низкий** процент отказов. Скорость и стабильность — не компромисс, который ты балансируешь, а два следствия одной причины: кодовой базы, которую можно менять уверенно. Хорошая архитектура и есть то, что покупает эту уверенность. Выбор «быстро против качественно» ложный; дешёвые команды просто медленно не получают ни того, ни другого. ## Где правила реально двигают рычаг Вот часть, которая важна на практике. SOLID, DRY, KISS, DI — не академический вкус. Каждое — рычаг на форму той самой кривой: - **Single responsibility** (S в SOLID): изменение трогает одно место, а не девять. Радиус поражения каждой правки остаётся маленьким — это разница между «два часа» и «две недели плюс регрессия в checkout». - **DRY — один источник правды на факт:** когда правило живёт ровно в одном месте, ты меняешь его один раз. Когда оно скопировано в восьми, ты меняешь восемь раз и забываешь девятое — и девятое и есть тот баг, который уезжает в прод. - **KISS:** самое простое, что работает, — самое дешёвое для понимания, а большая часть стоимости софта — не в том, чтобы его _писать_, а в том, чтобы его _читать_. Каждая капля твоей сегодняшней «умности» — налог, который платит каждый будущий читатель, включая тебя через полгода, без всякой памяти о том, зачем это было. - **DI — внедрение зависимостей:** когда части зависят от контрактов, а не от конкретных реализаций, их можно подменять, тестировать и менять по отдельности. (Я поменял AI-провайдера под этим самым сайтом, изменив одно значение в конфиге, а не переписывая фичу. Это DI покупает плоскую кривую.) Ни одно из этих правил не про красоту. Все они — про то, чтобы не дать усилиям-на-изменение лезть вверх. ## Почему это так трудно продать Причина, по которой «давай по-быстрому» постоянно выигрывает спор, — бухгалтерский трюк: **экономия мгновенна и видна; затрата отложена и невидима — и падает на другого человека.** Основатель, сказавший «пока дёшево», записывает себе победу в этом квартале. Команда, которая наследует кодовую базу, платит проценты годами. Эта асимметрия и есть причина, почему дешёвый вариант выигрывает совещание — ровно до того момента, когда проигрывает компанию. И поэтому же почти никто не верит этому из статьи. Верят после того, как прожили это однажды — после переписывания, после квартала, в котором роадмап не сдвинулся, после ухода сеньора, для которого каждое изменение стало дракой. Хорошая архитектура — это урок, который выучивают дорогим способом и потом уже не разучиваются. Её ценность приходит вместе с рубцами. За архитектуру можно заплатить заранее — валютой, которую ты контролируешь: чуть больше времени на дизайн, чуть больше дисциплины, несколько принципов, которых держишься последовательно. Или можно заплатить за её отсутствие потом — валютой, которую не контролируешь: упавшей скоростью, сорванными оценками, продуктом, который больше не может двигаться, и в итоге переписыванием, которое может не успеть. Счёт придёт в любом случае. Выбираешь ты только процентную ставку. «Дёшево» никогда не было дешёвым вариантом.