Разработка
Технический долг: как оценить компромисс и его исправление
Метафора для внутренних ограничений системы, из-за которых следующие изменения требуют дополнительных усилий. Обсуждать такой долг полезно через конкретное решение, его последствия и способ устранения.
Редакция:
Фраза «на сайте много технического долга» сама по себе не объясняет, за что предлагается платить. Попросите показать конкретное ограничение, изменение, которому оно мешает, и результат предлагаемой работы. По возрасту сайта или названию его CMS нельзя определить необходимость полной переписки.
В объяснении Мартина Фаулера дополнительные усилия на дальнейшие изменения сравниваются с процентами по долгу. Автор также подчёркивает неточность оценок будущих затрат. Это полезная метафора для обсуждения решения, без гарантированной финансовой доходности исправлений. Источник проверен 2 ноября 2026 года.
Учебный компромисс DEBT-39
В вымышленном проекте запускают две страницы услуг с формами обращения. Подрядчик предлагает временно оставить два отдельных обработчика одинаковых правил проверки полей, чтобы не расширять текущую задачу объединением кода. У каждого обработчика есть серверная проверка и тесты; доставка обращения проверяется отдельно. Это пример для обсуждения, не описание проекта CoreWeb и не рекомендация копировать обработчики.
Заказчик соглашается на ограниченный вариант только после разбора последствий. Когда изменится общее правило поля, его придётся обновить и проверить в двух местах. Появится риск, что формы начнут вести себя по-разному. Отсутствие обязательной проверки данных или потеря обращения в этом примере были бы дефектами выпуска; назвать их «долгом» недостаточно, чтобы считать работу принятой.
Карточка решения
| Поле DEBT-39 | Что зафиксировано в примере |
|---|---|
| Граница временного решения | Два обработчика используют одинаковые правила, но меняются отдельно; остальные части сайта не включены в эту запись |
| Основание | Сравнены текущий выпуск и объединение правил; последствия и дополнительная работа показаны до решения |
| Цена следующего изменения | Проверить два места изменения, тесты обоих обработчиков и поведение обеих форм |
| Владелец пересмотра | Ответственный за развитие сайта получает сигнал от подрядчика и принимает решение по оценённым вариантам |
| Событие пересмотра | Запрос на третью форму или первое изменение общего правила поля; отдельно — обнаруженное расхождение поведения |
| Контрольная встреча | Обсудить запись при планировании следующего выпуска, даже если событие ещё не наступило |
| Результат устранения | Одно согласованное место определения общих правил; обе формы сохраняют предусмотренное поведение и проходят проверки |
Назначьте конкретных ответственных и дату встречи в своём проекте. Формулировка «когда-нибудь отрефакторим» не задаёт следующего действия. Если третья форма уже входит в согласованный ближайший выпуск, основание временного решения нужно пересмотреть сразу.
Из чего складывается стоимость изменения
Для DEBT-39 поступил запрос: изменить общее правило поля «Комментарий» у обеих форм. Сравните варианты на одном результате: одинаковое согласованное поведение двух форм после выпуска.
| Вариант | Что включить в оценку | Что проверить в обосновании |
|---|---|---|
| Исправить два обработчика | Анализ текущих различий, две правки, тесты, проверка обеих форм и выпуск | Сохраняется ли риск расхождения при следующей общей правке; учтены ли обе точки приёма данных |
| Объединить общие правила сейчас | Всё необходимое для изменения поля, выделение общей логики, подключение двух обработчиков, регрессии и выпуск | Не объединены ли намеренные различия страниц; сохранены ли ответы об ошибке и успешный сценарий |
| Исследовать перед оценкой | Ограниченный разбор обработчиков и подтверждённый список различий | Какой неизвестный факт будет установлен и какие варианты можно будет оценить после этого |
Попросите отдельно показать разовую работу по устранению дублирования и работу по самому запросу. Не сравнивайте оценку «только написать общий модуль» с полной стоимостью второго варианта, включающей тесты и выпуск. Часы и цена должны опираться на изученный код и договорённый состав; в этом примере они не измерены.
Будущие изменения учитывайте по подтверждённому плану. Если ожидаемые новые формы пока лишь идея, предполагаемую экономию пометьте как гипотезу. При обнаруженном расхождении сначала оцените его последствия и необходимость исправления текущего поведения. Срочность дефекта может отличаться от приоритета общего улучшения устройства кода.
Как принять устранение долга
В учебном продолжении выбран общий модуль правил. Для закрытия DEBT-39 подрядчик показывает место их определения, обе подключённые формы и результаты проверок. Общий модуль без подключения второго обработчика оставляет часть первоначальной проблемы.
- Согласуйте примеры допустимого и недопустимого значения изменённого поля. Проверьте обе формы и оба серверных обработчика на одном наборе входных данных.
- Сверьте согласованные различия страниц: источник обращения, получателя и другие поля. Их случайное выравнивание не входит в задачу устранения дублирования.
- Проверьте показ ошибок, сохранение введённого текста и успешный путь до предусмотренного получателя на разрешённых тестовых данных. Новая организация кода должна сохранить эти сценарии.
- Зафиксируйте версии результата и доказательства. После выпуска проверьте применимые сценарии опубликованной версии; отметьте отдельно непроверенные внешние зависимости.
Если повторная общая правка по-прежнему требует менять два независимых определения, критерий DEBT-39 не выполнен. Если обнаружились другие ограничения, создайте отдельные записи с основаниями: одна закрытая карточка не означает, что весь сайт свободен от технического долга.
Что спросить перед согласованием
«Какое следующее изменение затрудняет это решение, что именно вы предлагаете исправить, какие варианты сравнили и чем подтвердим результат?» Ответ должен связывать техническую работу с наблюдаемым ограничением. Формулировки «устарело» и «надо переписать красиво» требуют конкретизации.
Запишите границы работы и исключения в плане состава сайта. Для изменения уже согласованного выпуска используйте карточку запроса на изменение. Полную переписку, точечное исправление и сохранение текущего решения сравнивают после обследования; сам термин не выбирает вариант за заказчика.