Дисклеймер:
Эта статья — субъективное мнение, крик души и попытка облечь в слова накопленную усталость и разочарование. Она не претендует на истину в последней инстанции и не ставит целью предложить конкретные решения, но надеется привлечь внимание к тихой эпидемии выгорания в наших рядах. Автор не стремится никого обидеть или обвинить, а лишь хочет донести важность осознания масштаба этой проблемы. Все совпадения с реальными проектами случайны и не преднамеренны.
«Беспорядок — это не технический долг. Беспорядок — это просто беспорядок» — Роберт Мартин, 22 сентября 2009 г.
Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса.
Долг (он же хаос) зарождается тогда, когда аналитики, загнанные в жесткие рамки бизнеса и стремящиеся угодить ему во что бы то ни стало, начинают брать на себя смелость оценивать трудоемкость, не обладая для этого достаточной экспертизой. Да, в теории мы должны совместно оценивать риски. Но на практике они не могут аргументированно отстоять реалистичные сроки, предпочитая соглашаться с любыми ожиданиями. Они видят функциональность, но не видят кода, думая, что новая фича — это просто добавить строчку.
И именно с этого момента продукт начинает медленно умирать, а вместе с ним и мы. То, что раньше делалось за час, теперь требует целого дня. Чтобы уложиться в сроки, разработчики вынуждены вечеровать и ночевать. Каждое изменение — это игра в русскую рулетку. Исправил баг — получи два, исправил два — получи четыре. И так по кругу — бесконечная погоня за собственным хвостом, где каждый спринт лишь отдаляет момент полного краха, а моральная усталость становится постоянным спутником тех, кто когда-то верил в проект.
Архитектура размывается бесконечными компромиссами. Вместо четких границ — спагетти-код, где всё связано со всем. Да, иногда временные решения оправданы. Но когда «временно» становится постоянной стратегией, фундамент начинает рушиться. Монолит обрастает непредсказуемыми связями, микросервисы превращаются в распределённого монстра. Эти компромиссы словно трещины в фундаменте — сначала их не видно, но однажды здание рухнет.
А в эпицентре этого хаоса — «герои». Они отказываются продумывать архитектуру, считая это пустой тратой времени. Они гордятся тем, что не читают документацию, изобретая свои «кривые велосипеды». Их код — это лабиринт, в котором есть только один ключ — они сами. Аналитики их обожают, ведь те всегда делают «прямо сейчас», прикрывая свои архитектурные преступления «потребностями бизнеса». Они становятся незаменимыми узниками системы, которую сами и создали.
И здесь проявляется фундаментальный закон проекта: степень хаоса в коде делает невозможным использование инструментов, предназначенных для порядка. Это не баг, это фича системы. Любые разговоры о CI/CD и тестах разбиваются об этот железный закон. Они бессильны против архитектуры, где всё связано со всем. В конце концов деградация приводит к невозможности писать эти самые тесты. Хрупкие, спутанные зависимости, функции с десятком побочных эффектов. Любая попытка покрыть код тестами наталкивается на стену. В лучшем случае, вместо модульных тестов — горстка скриптов, которые симулируют работу, но не дают никакой уверенности. Отсутствие тестов означает, что каждое изменение — это прыжок с завязанными глазами. Релиз превращается в ад, полный паники и горячих фиксов.
Процессы деградируют вместе с кодом. Апрувы на MR превращаются в пустую формальность. Клич в канал разработки: «Коллеги, срочно нужен апрув!» — и вуаля, через 3 минуты две галочки сверкают на ещё не остывшем запросе на слияние… Никто не задаёт вопросов, никто не спрашивает об архитектуре. Главное — поставить галочки и влить в мастер. Система контроля качества становится фикцией.
Те, кто пытается бороться за чистоту, быстро выгорают. Более того, они становятся изгоями, а их голос тонет в аргументах «надо быстрее». Аналитики начинают видеть в них препятствие для закрытия стори, а на высказывания со словами «рефакторинг» реагируют как вампиры на чеснок. В итоге эти недооценённые изгои смотрят, как творение, в которое они вкладывали душу, превращается в монстра, и уходят. Остаются те, кто смирился с грязью, и те, кто ею управляет.
Итог предсказуем. Больше всех страдают разработчики. Постоянный стресс от «пожаров», стыд за собственный код, чувство вины за неизбежные ошибки и ощущение бессмысленной траты сил — вот цена компромиссов. Исчезает радость от решения задач, креативность, вера в свои силы. Остаётся лишь выжженное поле апатии и раздражения.
В финале бизнес получает то, что хотел — продукт работает. Но это не триумф, а отсрочка приговора. Ценой стали выгоревшие люди и лабиринт кода, в котором завтра снова заблудится и выгорит новая команда. Труд не напрасен, но он обесценен, ведь каждый следующий шаг будет даваться в десять раз тяжелее. Система жива, но её будущее — это бесконечная борьба с последствиями вчерашних компромиссов.
Комментарии (15)

ArthurPanfilov
23.11.2025 09:17Могу добавить от себя следующее - независимо от опыта специалиста и умения граммотно писать код (архитектура, паттерны, тесты и все такое) нужно еще оценивать собственную роль и обстановку в команде, в которой работаешь. Есть мнение, что если это сразу учитывать на входе, то и на выходе будет меньше разочарований.
В одном случае проще расслабить булки и плыть по течению. В другом - можно упереться и практически в одно лицо вытащить на более качественный уровень разработку. Если же заручиться поддержкой бизнеса или технических руководителей, то можно и команду вытащить на более качественный уровень. Но это уже не про написание кода.

pravosleva
23.11.2025 09:17Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.
Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )
Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.

SergeyEgorov
23.11.2025 09:17Чтобы не выгорать - не выгорайте :-)
Исправляйте ошибки до того, как они появились :-)

pravosleva
23.11.2025 09:17Попробуйте прочитать ещё раз. Возможно не с первого раза, но что-то новое без сомнения должно открыться. Главное, не останавливайтесь на полпути )

SergeyEgorov
23.11.2025 09:17Прочитал. Понимаю что возможно мне следует переключиться на абстракции... :-)

zababurin
23.11.2025 09:17По этому я свою архитектуру на работе начал писать, которая мне нужна. Это все согласованно было, никакой отсебятины. Результат. За три года из тестового проекта, проект превратился в микрофронтенды и продолжает очищаться.
У меня обратный процесс получился. Он бардака к структурированности

dkfbm
23.11.2025 09:17Всего: 60
Не обижайтесь, но боюсь, в статье речь о проектах несколько иного масштаба.

HardlinePeak936
23.11.2025 09:17Поддерживаю, у меня в голове всплыла активная ветвь «Garbage» на сотню объёмных модулей, как ирония ради психологической защиты в одном проекте...
P.s. Впрочем, там действительно было временным решением, а потому от этого избавились. Через почти полтора года.
P.p.s. Там модули от множества сервисов было, если что ;)

Vadik_prog
23.11.2025 09:17Еще хуже идеальный код с точки зрения архитектуры, но с нулевой бизнес отдачей

megadrugo2009
23.11.2025 09:17Если код ни как не влияет на бизнес - то это идеальный код.
То есть внедрение новых фич, поддержка старых, негативно не сказываются на бизнесе.

HardlinePeak936
23.11.2025 09:17Они видят функциональность, но не видят кода, думая, что новая фича — это просто добавить строчку.
Зависит от фичи и среды... В остальном — статью пролистал, а она оказалась короче, чем я ожидал ;)

Samhuawei
23.11.2025 09:17Работал в продуктовой компании которая выкатывала новый продукт раз в две недели. На одной кодобазе, но с разными отличиями для вендоров. Там техдолг составлял 30000 тикетов джиры. Но никто не парился. Заказчик платит не за архитектору, а за готовое решение. А если тикет не перешёл с техдолга в прод за год значит он никому не нужен.
T700
Так и бывает. Бесконечное усложнение. Это проявляется в любом по и даже open source. И чем система становится больше, тем аккуратнее, продуманее, документированее, системнее, должен каждый следующий шаг. Это системная работа по изучению нового фунционала, его будущего использования и влияния на всю систему. Спешка тут недопустима.