Технический долг сайта: почему доработки со временем дорожают

Технический долг сайта - это цена, которую вы платите не сразу, а через полгода-год: за быстрый хак на Tilda, за скопированный без разбора кусок JS, за интеграцию, которую собирали в спешке перед распродажей. Я регулярно захожу в чужие проекты на доработку и вижу одну и ту же картину. Простая правка на Tilda в моём прайсе стоит от 3 000 ₽, но стоит копнуть глубже, и то же самое требование превращается в комплексную интеграцию с CRM или эквайрингом от 40 000 ₽: вокруг простой задачи нарос слой костылей, которые сначала нужно распутать. Для бизнеса это выглядит так: тот же самый список хотелок в ТЗ, но смета на следующий этап растёт без видимой причины, хотя разработчик вроде бы работает так же быстро, как раньше.

Что копится в технический долг сайта

Долгом становится не любой быстрый костыль, а тот, который никто не разобрал и не задокументировал. Разработчик под дедлайн хардкодит скидку в JS-файле Tilda вместо того, чтобы вынести значение в настройки блока, и это нормально, если через неделю он вернётся и перепишет по-человечески. Проблема начинается, когда возвращаться некому: сайт передают другому специалисту, тот добавляет свой костыль поверх, и через два-три таких цикла код превращается в слоёный пирог, где никто не понимает, какой слой за что отвечает.

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

На практике долг чаще всего копится в четырёх местах.

• Точечные доработки без документации: кастомный скрипт для Tilda решает конкретную задачу, но нигде не описано, как он работает и какие блоки на странице от него зависят.
• Интеграции, собранные под конкретную акцию: обвязка вокруг эквайринга T‑Bank или API СДЭК, которую писали за три дня до запуска и не привели в порядок после.
• Automation-цепочки без структуры: сценарии в n8n или обработчики в aiogram-боте растут органически, сначала бот отвечал на пять команд, через год на сорок, а структура осталась прежней.
• Устаревшие зависимости и версии платформ: плагины WordPress, которые не обновляли два года из опасения что-то сломать, и это усложнило любое обновление ядра.

Почему доработки дорожают: механика роста цены

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

Пример из практики. Заказчик просит добавить второй способ оплаты на сайт, где уже стоит эквайринг T‑Bank, интегрированный в WooCommerce. Формально задача простая: подключить ещё один платёжный шлюз. Но если предыдущая интеграция обрабатывала статусы заказа хардкодом в functions.php, без хуков и без документации, сначала нужно вычленить эту логику, понять, от чего она зависит, и только потом писать новый код так, чтобы не сломать первый способ оплаты. В похожем проекте распутывание таких хардкодов заняло около шести часов, хотя сама интеграция нового шлюза потребовала бы часа два.

Где на практике чаще всего копится долг

Tilda-скрипты без версионирования

Кастомные скрипты для Tilda обычно живут прямо в настройках Zero-блока или во вставке кода на странице, без git и без резервных копий. Когда таких вставок на сайте пять-шесть и каждая правилась разными людьми в разное время, найти, где именно зашита логика зон доставки СДЭК или ограничение на промокод, превращается в отдельную задачу. Я видел проекты, где ограничение промокодов было продублировано в трёх разных скриптах с разными условиями, потому что каждый новый разработчик писал свой вариант, не найдя старый. То же самое происходит с конвертацией валют или расчётом НДС на сайте: если формулу один раз вписали прямо в код блока, а не вынесли в понятную функцию, при следующем изменении ставки её будут искать по всему проекту.

Автоматизация в n8n и ботах без структуры

С n8n похожая история: сценарий из пяти нод быстро обрастает условиями, HTTP-запросами и вебхуками, и через полгода в нём пятьдесят нод без единого комментария и без внятных названий. То же с aiogram-ботами: обработчик /start изначально отвечал на одну команду, а через год в нём накопилась логика регистрации, проверки подписки и выдачи промокода, потому что каждую новую фичу дописывали в тот же файл, лишь бы работало. У меня был случай, когда клиент попросил перенести бота на нового провайдера хостинга, и первые два часа ушли не на перенос, а на то, чтобы понять, какие переменные окружения вообще используются и что случится, если убрать необработанное исключение в одном из хендлеров.

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

Признаки, по которым можно посчитать технический долг сайта

Прежде чем звать разработчика на рефакторинг, посмотрите на проект по этим сигналам.

Сколько стоит игнорировать технический долг проекта

Долг не платится сам, он копится с процентами. Ситуация типична: сайт три года жил без единой правки архитектуры, обрастал скриптами под каждую акцию, а потом бизнес решил переехать на новую CRM. Аудит перед миграцией показал, что часть логики продублирована, часть вообще не используется, а часть держится на одном плагине, который никто не поддерживает. Сама миграция после этого заняла в полтора раза больше времени, чем планировали. Если на сайте до сих пор ограничение промокодов или зоны доставки собраны руками прямо в блоке Tilda, дешевле один раз поставить готовые скрипты для Tilda, которые уже протестированы и не тянут за собой историю правок трёхлетней давности.

С WordPress тоже самое работает в обратную сторону: заброшенные плагины и неотслеживаемые обновления часто становятся источником заражений, а лечение сайта от вирусов и восстановление после заражения стоит от 15 000 ₽ и растёт вместе с объёмом восстановления. Регулярная техническая поддержка обходится дешевле разового пожара: у меня она стоит от 15 000 ₽ в месяц и включает профилактику подобных ситуаций, а не только реакцию на уже случившееся.

Как снижать технический долг сайта и не наращивать новый

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

• Заведите репозиторий даже для кастомных скриптов на Tilda. Git не привязан к платформе, а история изменений экономит часы на выяснение, кто и зачем что-то поменял, особенно если над проектом в разное время работали разные подрядчики.
• Называйте ноды и сценарии в n8n так, чтобы через полгода было понятно, что делает цепочка, без необходимости открывать каждую ноду по очереди и прослеживать её вручную.
• Разносите обработчики в aiogram-боте по модулям с самого начала: регистрация, платежи, рассылки, каждая логика в своём файле, а не в одном main.py на полторы тысячи строк.
• Планируйте время на рефакторинг заранее, а не только когда правка уже стала невозможной. Час на приведение кода в порядок сегодня экономит день на распутывание через год.
• Перед передачей проекта новому разработчику или подрядчику фиксируйте карту интеграций: какие сервисы подключены, где хранятся ключи, что произойдёт, если один из них отключить. Это экономит первый день работы нового человека, который иначе уйдёт на археологию вместо задач.

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

Частые вопросы

Как понять, что сайту нужен рефакторинг, а не новая фича?

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

Можно ли снизить технический долг без переписывания сайта с нуля?

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

Сколько стоит устранить технический долг сайта?

Зависит от масштаба. Точечная доработка на Tilda с распутыванием старого скрипта начинается от 3 000 ₽, комплексный аудит с интеграциями CRM или эквайринга обойдётся от 40 000 ₽. Итоговую цифру я называю после того, как посмотрю проект, а не по общей оценке на глаз, потому что объём хардкода в двух похожих на первый взгляд сайтах может отличаться в разы.

Что будет, если игнорировать технический долг годами?

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