Небольшая доработка требует правок в нескольких местах. После обновления приходится вручную проверять старые интеграции, а важное правило известно только одному разработчику. Такие ситуации стоит разбирать по причинам: где система усложняет следующую работу и что можно изменить.
В Гуси-Лебеди мы предлагаем обсуждать технический долг через конкретные ограничения, затраты и проверки. Разберём, что считать долгом, как составить реестр и выбрать между постепенной доработкой и заменой системы. Примеры ниже учебные, они не описывают результаты проектов компании.
Что такое технический долг простыми словами
Технический долг представляет собой ограничения внутреннего устройства продукта, которые добавляют работу при его изменении. В объяснении Мартина Фаулера дополнительное усилие сравнивается с процентами, а устранение ограничения с погашением долга. Это метафора для обсуждения решений, а не бухгалтерская задолженность.
Представим, что цена заказа вычисляется отдельно на сайте и в интеграции. При изменении правила нужно найти и согласованно обновить обе реализации. Если правило собрано в одном проверяемом модуле, следующую доработку проще обсуждать и контролировать. Само наличие двух реализаций ещё не доказывает проблему: подтвердите расхождения или лишние действия в истории изменений.
Не называйте долгом всё, что команде не нравится. Ошибка нарушает нужное поведение, новая функция расширяет возможности, а долг объясняет, почему сопровождение или изменение обходится сложнее. Эти задачи могут быть связаны, но для каждой нужен собственный результат.
Возраст сайта или знакомый разработчику стек не являются достаточным основанием для переписывания. Сначала выясните, какое ограничение мешает проекту и будет ли устранение полезно для запланированной работы. Для этого подходит аудит существующего проекта с изучением кода, зависимостей и процессов выпуска.
Почему долг появляется и когда компромисс допустим
Временное решение может быть осознанным: команда выпускает ограниченный сценарий, фиксирует последствия и планирует возврат к нему. Другая ситуация возникает, когда ограничение обнаружилось позже, после накопления знаний о продукте. В Technical Debt Quadrant Фаулер разделяет осознанные и непреднамеренные решения, а также разумные и неосторожные компромиссы.
Для временного решения запишите, какую задачу оно позволяет закончить, что усложняет и при каком событии его нужно пересмотреть. Фраза «потом исправим» без владельца и условия возврата не помогает планированию. Предел может быть связан с новой интеграцией, увеличением вариантов продукта или изменением правила доступа.
Возможные источники долга стоит искать в повторяющейся логике, неясных границах модулей, ручных операциях выпуска, недостатке проверок и неполной документации. Устаревшая зависимость требует отдельной оценки совместимости, поддержки и риска. Не делайте вывод о безопасности только по возрасту компонента.
Для обсуждения компромисса полезно ответить на три вопроса: зачем принимаем ограничение, как заметим последствия и кто пересмотрит решение. Оценки сроков и стоимости фиксируйте как оценки, пока они не подтверждены фактической работой.
Как обнаружить технический долг на сайте
Начните с истории задач и выпусков. Выберите повторяющиеся изменения и посмотрите, какие дополнительные действия нужны каждый раз. Причина должна объяснять наблюдаемый эффект: дублирующее правило требует нескольких правок, скрытая зависимость вызывает повторную проверку, ручной перенос настройки добавляет операцию.
| Наблюдение | Что проверить | Как описать ограничение |
|---|---|---|
| Одно правило меняют в нескольких местах | Связанные реализации и историю расхождений | Дублирование конкретной логики |
| Выпуск зависит от ручных действий | Инструкцию и фактические шаги | Неавтоматизированная операция с известным риском |
| Нужный модуль трудно проверить отдельно | Границы зависимостей и тестовые данные | Связность, которая мешает проверке |
| Интеграцию понимает только один человек | Контракт, документацию и обработку ошибок | Недостаток знаний для сопровождения |
Показатели анализатора кода помогают выбрать места для просмотра, но не заменяют оценку поведения и задач. Высокая сложность функции является сигналом для изучения. Её наличие само по себе не доказывает, сколько денег теряет бизнес или что весь проект нужно заменить.
Например, для API-интеграции сопоставьте повторяющиеся ошибки с правилами повторной отправки и контрактом данных. Для выпуска проверьте последовательность операций и способ восстановления. Отделяйте подтверждённую причину от гипотезы, которую ещё предстоит воспроизвести.
Если нет журналов или истории задач, честно укажите этот пробел. Можно начать с ограниченного разбора одного сценария. Нельзя подменять отсутствие данных общим утверждением, что технический долг обязательно растёт с заданной скоростью.
Как оценить долг и расставить приоритеты
Для каждого ограничения заведите карточку: участок системы, наблюдение, подтверждение, последствия, варианты исправления, трудоёмкость, ответственный и критерий приёмки. Добавьте задачи продукта, которые затронет это место. Тогда техническая работа получает понятную связь с развитием сайта.
Приоритет зависит от частоты изменений, важности сценария, подтверждённого риска и стоимости исправления. Неудобный, но редко меняющийся модуль может подождать. Ограничение в постоянно дорабатываемом расчёте заказа стоит рассмотреть раньше. Срочная неисправность или подтверждённая уязвимость требуют отдельного решения, а не ожидания общей очереди рефакторинга.
Если есть данные о повторных затратах, сравните их с оценкой исправления на выбранном горизонте. Укажите, какие значения измерены, а какие предполагаются. Не используйте универсальный процент экономии и не обещайте окупаемость без исходных данных. Полезнее показать диапазон и условия, при которых решение меняется.
Не назначайте всей команде одинаковую долю времени на долг без обсуждения контекста. Согласуйте конкретный набор ограничений на ближайший цикл и возможный объём работы. Для модернизации действующей системы это помогает выбрать небольшое изменение, которое можно проверить до расширения работ.
Рефакторинг или переписывание: как выбрать способ исправления
Рефакторинг меняет внутреннее устройство при сохранении нужного внешнего поведения. Замена компонента или всей системы может затронуть контракты, данные и процессы. Сначала опишите поведение, которое следует сохранить, и границу изменения. Иначе команда рискует воспроизвести старые ограничения в новом коде.
Рассмотрите постепенную замену отдельных частей. Подход Strangler Fig описывает модернизацию через перенос частей поведения из существующей системы в новую. Для этого нужны границы, на которых старое и новое решение могут временно сосуществовать.
Учебный пример: перед заменой расчёта цены сохраните проверяемые правила скидок и округления. Подготовьте контрольные данные, сравните результаты старого и нового модуля, разберите отличия. Затем согласуйте переключение, наблюдение и возврат. При изменении схемы данных отдельно проверьте, сможет ли прежний код работать после отката.
Для изменений с побочными эффектами нельзя бездумно выполнять оба варианта параллельно: можно создать два заказа или две отправки. Выбирайте безопасный способ сравнения. Смена технологии сама по себе не решает эти вопросы; сначала определите требования, затем обсуждайте выбор backend-стека.
Как принять результат и не накопить долг снова
Приёмка должна проверять устранённое ограничение и сохранённую функцию. Недостаточно отметить, что код стал короче. Покажите, как теперь выполняется нужное изменение, какие проверки доступны и что больше не требует прежнего ручного действия.
| До работы | После работы | Доказательство результата |
|---|---|---|
| Правило дублировалось | Есть согласованная точка изменения | Контрольные сценарии и список затронутых мест |
| Выпуск требовал ручного шага | Шаг автоматизирован или явно контролируется | Повторяемый выпуск и запись выполнения |
| Ошибки интеграции были неясны | Понятны исход и порядок восстановления | Проверка ошибок и журнал событий |
| Не было описания модуля | Зафиксированы контракт и ограничения | Документация, пригодная для другого разработчика |
После выпуска проверьте доступность и пользовательские сценарии. Сравнивайте реальные затраты только для сопоставимых задач, учитывая другие изменения процесса. Если ожидаемый эффект не подтвердился, пересмотрите причину и план, а не объявляйте успех по факту переписывания.
В новых решениях фиксируйте важные компромиссы, поддерживайте проверки и пересматривайте реестр при планировании. Не обязательно устранить все несовершенства сразу. Важно, чтобы ограничения были видимы и у команды был понятный способ вернуться к ним.
В Гуси-Лебеди мы предлагаем начинать с одного подтверждённого узкого места. Его можно описать, исправить и проверить. Такая работа даёт основание для следующего этапа и помогает обсуждать развитие проекта на понятном языке.