Короткий ответ
Технический долг web-портала оценивают не по ощущению “код старый”, а по влиянию на бизнес: насколько долг замедляет доработки, ломает релизы, усложняет поддержку, мешает интеграциям и повышает риск потери данных.
Переписывать весь проект сразу обычно не нужно. Сначала стоит собрать карту долга, разделить его по критичности и понять, какие зоны действительно мешают развитию, а какие можно оставить под контролем.
Что считать техническим долгом
Технический долг - это не любой несовершенный код. В зрелом проекте всегда есть компромиссы. Проблемой долг становится тогда, когда он влияет на решения бизнеса.
К техническому долгу web-портала стоит относить:
- участки кода, которые сложно менять без побочных ошибок;
- модули, где нет понятных владельцев и документации;
- интеграции, которые работают только при ручном контроле;
- данные, у которых нет единого источника истины;
- архитектурные ограничения, из-за которых простые задачи оцениваются как сложные;
- устаревшие зависимости, влияющие на безопасность, поддержку или релизы;
- процессы, где качество держится на памяти отдельных людей.
Если долг не мешает пользователям, бизнесу и команде, его можно держать в backlog. Если он регулярно увеличивает сроки и риски, его нужно оценивать как управленческую проблему.
Почему не стоит начинать с переписывания
Переписывание выглядит понятным решением: старое убрать, новое сделать правильно. Но без диагностики это часто переносит хаос в новую систему.
Риск переписывания без аудита в том, что команда:
- не знает всех бизнес-правил, которые накопились в старой системе;
- теряет скрытые сценарии пользователей;
- недооценивает интеграции с CRM, 1С, складами, бухгалтерией или внутренними сервисами;
- повторяет старые ошибки в новой архитектуре;
- останавливает развитие на месяцы без понятной точки возврата.
Если портал уже сложно развивать, сначала нужно понять, где именно причина: в архитектуре, данных, интеграциях, документации, процессе релизов или работе подрядчика. Это близко к ситуации, когда портал невозможно развивать без предварительной карты рисков.
Отдельно полезно разобрать управленческий выбор: переписывать проект или сначала стабилизировать. Это помогает не путать технический долг с ситуацией, где действительно нужна новая архитектура.
Карта оценки технического долга
Для первичной оценки удобно смотреть проект по слоям.
1. Бизнес-логика
Проверьте, описаны ли роли пользователей, статусы, исключения, ручные действия и критичные процессы.
Признаки долга:
- правила работы портала объясняют только отдельные сотрудники;
- один сценарий по-разному понимают бизнес, аналитик и разработчик;
- новые задачи требуют долгих уточнений;
- нет актуального описания ключевых пользовательских путей.
Если бизнес-логика живёт в переписках, даже чистый код будет трудно развивать.
2. Архитектура и модули
Проверьте, можно ли показать схему основных модулей и зависимостей.
Признаки долга:
- изменение одного раздела затрагивает несколько несвязанных функций;
- команда не может заранее сказать, что сломается после доработки;
- нет понятной границы между личным кабинетом, админкой, интеграциями и отчётами;
- оценка задачи начинается с длительного исследования.
Такая ситуация часто объясняет, почему доработки портала становятся дороже.
3. Интеграции и данные
Проверьте обмены с CRM, 1С, внешними API, платёжными системами, складом, телефонией и внутренними сервисами.
Признаки долга:
- один и тот же объект хранится в нескольких системах с разными значениями;
- ошибки интеграций находят пользователи, а не мониторинг;
- обмены поддерживаются ручными сверками;
- непонятно, какая система является источником истины.
Если интеграции не описаны, любая новая функция может неожиданно затронуть несколько систем. Подробнее это разобрано в статье почему интеграции ломают портал.
4. Релизы и качество
Проверьте, как изменения попадают в продакшен и что считается готовностью.
Признаки долга:
- после релиза регулярно появляются ошибки в соседних функциях;
- нет понятного набора регрессионных проверок;
- релизы зависят от одного разработчика;
- план отката не описан;
- ошибки закрывают вручную без анализа причины.
Здесь технический долг уже влияет не только на скорость, но и на доверие пользователей к системе.
5. Документация и передача
Проверьте, сможет ли новая команда принять проект без повторного расследования.
Признаки долга:
- нет карты модулей, окружений, доступов и интеграций;
- правила деплоя и запуска проекта не зафиксированы;
- нестандартные решения не описаны;
- знания находятся в чатах и памяти команды;
- подрядчик сдаёт функции, но не передаёт технический контекст.
Если документации нет, технический долг становится зависимостью от людей. В этом случае стоит сначала восстановить минимальную карту проекта, а не запускать новые крупные доработки.
Как расставить приоритеты
После первичной карты не нужно чинить всё сразу. Разделите долг на четыре группы.
Первая группа - критичный долг. Он влияет на деньги, данные, безопасность, стабильность или сроки ближайшего релиза. Его нужно включать в ближайший план.
Вторая группа - долг, который блокирует развитие. Например, модуль нельзя дорабатывать без риска для соседних функций. Его нужно разбирать перед крупными задачами.
Третья группа - долг поддержки. Он замедляет команду, но не блокирует бизнес прямо сейчас. Его можно закрывать постепенно.
Четвёртая группа - допустимый долг. Он известен, описан и не мешает ближайшим решениям. Его достаточно держать под контролем.
Такой подход помогает уйти от общего спора “проект плохой” к понятному списку рисков и решений.
Какие вопросы задать команде
Перед решением о рефакторинге, восстановлении или переписывании стоит задать подрядчику или внутренней команде конкретные вопросы:
- какие зоны проекта сейчас самые рискованные;
- какие доработки нельзя оценить без предварительного исследования;
- где чаще всего появляются ошибки после релиза;
- какие интеграции не имеют понятного владельца;
- какие документы нужны для передачи проекта;
- какие зависимости устарели и чем это грозит;
- что нужно сделать, чтобы следующая крупная доработка была безопасной.
Если ответы общие, лучше начать с аудита web-проекта, а не с немедленного рефакторинга.
Когда всё-таки нужна переработка архитектуры
Иногда точечные исправления уже не помогают. Переработка архитектуры может быть оправдана, если:
- новая функциональность постоянно ломает старую;
- ключевые бизнес-процессы невозможно развивать без обходных решений;
- данные расходятся между системами и требуют ручной сверки;
- безопасность или поддержка зависят от устаревших компонентов;
- стоимость изменений растёт быстрее, чем польза от новых функций;
- передача проекта другой команде невозможна без восстановления архитектурной картины.
Если таких признаков несколько, это уже похоже не на обычный технический долг, а на технический тупик проекта, где сначала нужна диагностика причин и сценарий восстановления.
Если главный симптом - повторяющиеся сбои после релизов, отдельно разберите сценарий портал ломается после релизов: там важно проверить не только код, но и регрессии, окружения, данные, интеграции и процесс выпуска изменений.
Но даже в этом случае нужно начинать с дорожной карты. В сложных проектах полезен формат восстановления web/AI-проекта: сначала стабилизация, затем документация, архитектурные решения и только потом развитие.
Что можно сделать без большого проекта
Если переписывание сейчас не подходит, можно начать с управляемых шагов:
- Собрать карту модулей, интеграций и критичных сценариев.
- Отметить зоны, где доработки чаще всего создают ошибки.
- Зафиксировать минимальную документацию для поддержки и передачи.
- Ввести проверку влияния перед каждой крупной задачей.
- Разделить долг на критичный, блокирующий, поддерживающий и допустимый.
- Связать погашение долга с конкретными бизнес-задачами.
Так технический долг перестаёт быть абстрактной технической жалобой и становится частью планирования.
Практический вывод
Технический долг web-портала не нужно оценивать эмоционально. Его нужно связывать с рисками, сроками, стоимостью развития, стабильностью и возможностью передать проект другой команде.
Если долг виден только в коде, он останется внутренней проблемой разработчиков. Если его перевести в карту рисков и решений, бизнес сможет выбрать разумный маршрут: точечная стабилизация, восстановление документации, контроль подрядчика, архитектурная переработка или постепенное развитие без переписывания всего проекта.
Для первичной самопроверки можно использовать чек-лист проблемного web-проекта.
