Клиент или CEO давит: "Надо вчера, бюджет около-нулевой!"   И первое, что летит в адское пламя экономии - тесты, чистая архитектура, документирование. Кажется, сэкономили время, деньги, клиент счастлив…  А вот фиг-то там. Говорю как CTO, который и сам так грешил.        Сегодня "сэкономил" 100 часов, а через полгода тратишь 500 на поддержку этого хаоса. И фикс багов на каждом чихе. Но и другая крайность - когда неделями шлифуешь идеальный код для фичи, которую выпилишь через месяц - то ещё удовольствие. Расскажу на реальных косяках, как найти золотую середину.        Помню одну CRM: взяли на поддержку систему, вроде все работает, даже красиво. Это пока мы не заглянули в код. Лучше бы мы этого не делали, честно…    Компоненты переплетены намертво, тестов - ноль. Любое изменение превращалось в лотерею: починишь отчет и гадаешь, что сломается дальше: рассылка, клиенты, или что ещё?     Добавление фичи растягивалось в 2-4 раза: полдня на задачу, три дня на поиск того, что ещё сломалось. Команда ненавидела проект, клиент платил не за фичи, а за наши мучения.    Выгребали постепенно: рефакторили только то, что трогали, потихоньку покрывали тестами. Итог: клиент спас систему, но заплатил кратно больше, чем если бы изначально вложился в нормальную архитектуру.        👉 Техдолг - не страшилка CTO. Это реальные сверх-часы и сорванные сроки. И платит за них в итоге клиент.        Контраст - наша система парсинга, которая не сдохла через пол года.   Задача: сделать систему парсеров, устойчивую к изменениям сайтов-источников. Без фанатизма в виде само-обучения, а просто легко исправляемый.    Сперва, сделали модульным - добавление нового источника стало занимать пол дня вместо 2-3, как часто бывает.    Автотесты: запустил - сразу видно поломку. Да, тесты на парсинг. Да, с реальными страницами.    Мониторинг орал в телегу при изменении вёрстки. Клиент сам мог легко поменять  селекторы в конфиге. Или отдать любому вебмастеру, который даже python ни разу не видел.     "Плагины" (они же middleware) позволили добавить обработку без переписывания ядра.    Итог: 80% проблем чинились правкой конфига за 5 минут, система жила годами без переделок.        Клиенты возвращались не из-за технической зависимости, а потому что доверяли. Вывел 4 железных правила.    Я не фанатик - в условиях жёстких бюджетов и классического “вчера” жертвую чистотой, но не сутью:     1️⃣ Пишем понятный код.    Тут и говорить нечего. Базовые принципы, ревью, голова - твои главные друзья.    2️⃣ Модули.    Не микросервисы ради микросервисов, но модули чаще всего нужны. Нет ада сильной связанности сплошных монолитов. Да и переиспользовать отдельный модуль легко. Минус время на то, что уже было сделано.    3️⃣ Тесты.    Не гоняемся за 100% покрытием, но, хотя бы базовые быть должны. Хотя бы функциональные.    4️⃣ Без магии!    Никакого хардкода, в котором кроме вас никому не разобраться!    Если клиент легко может найти другую команду на поддержку, он вероятнее всего вернётся именно к вам.    Парадокс, но работает. 90% наших клиентов - доказательство.        🔥 Эксперименты: Быстро и Грязно (с мозгом!) - только для гипотез с риском >50%. Железное правило: зашло → сразу рефакторим; не зашло → мгновенно удаляем. Никаких "потом"!

Личная боль из опыта разработки, породившая последнее правило: потратил недели на идеальную реализацию фитчи. Требование такое - все идеально, или никак (Об том, почему это тоже плохо в следующий раз). Юзеры проигнорировали. Удалили через несколько дней. Печаль, грусть и тоска от потерянного в пустую времени.

Вывод: иногда "быстро и криво" с последующей чисткой или удалением — меньшее зло, чем вбухивать ресурсы в пустоту.

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