Продукт работает, но каждое обновление дается команде все труднее. Прежде чем добавить новую функцию, разработчикам приходится разбираться в запутанном коде и искать способы обойти ограничения системы. Так может проявляться технический долг (technical debt).
В статье расскажем, как технический долг связан с багами, устаревшим кодом и рефакторингом, какие способы помогают его сократить и когда переделку разумнее отложить. Объясним, каких ошибок стоит избегать и почему попытка переписать весь проект не гарантирует избавления от долга.
Что такое технический долг
Технический долг (technical debt) — это недостатки в коде и устройстве программы, которые усложняют ее поддержку и развитие. Из-за них команда тратит дополнительные силы на каждую доработку: разбирается в запутанных связях, вносит одни и те же изменения в нескольких местах или ищет способы обойти ограничения системы. При этом для пользователей продукт может работать вполне исправно.
Представим интернет-магазин, в котором одна и та же скидка рассчитывается в корзине и при оформлении заказа. Чтобы быстрее запустить магазин, разработчики скопировали код расчета и теперь поддерживают две его версии. Когда условия акции меняются, приходится обновлять обе копии и проверять, что они дают одинаковый результат. Если забыть обновить одну из них, покупатель может увидеть разные суммы на соседних этапах покупки. Такое расхождение будет ошибкой программы. В этом примере дублирование кода создает технический долг. Разработчикам приходится обновлять обе копии, поэтому на изменения уходит больше времени. Вместе с тем растет и риск ошибок.
Дополнительное время на повторные правки и проверки можно сравнить с процентами по долгу. Чтобы сократить эти затраты, команда может вынести расчет скидки в общую функцию, к которой будут обращаться и корзина, и страница оформления заказа. Работа над такой переделкой соответствует погашению основного долга: разработчики тратят время сейчас, чтобы упростить последующие изменения. При этом проценты возникают, когда команда работает с проблемным участком, — само удлинение процессов не обязательно увеличивает расходы.
Иногда команда сознательно откладывает доработку кода, чтобы быстрее выпустить продукт. В других случаях ограничения выбранного решения обнаруживают позже, когда разработчики лучше понимают задачи проекта и требования к системе. Поэтому технический долг возникает и у опытных команд, которые внимательно следят за качеством кода.
Как измерить технический долг
Один из способов оценить технический долг — это сопоставление затрат на его устранение с затратами на дополнительную работу, которую приходится делать при поддержке продукта. Для этого команда составляет список конкретных проблем и примерно рассчитывает, сколько рабочих часов или дней понадобится на исправление каждой из них. Затем по истории выполненных задач оценивается, сколько времени уходит на обход ограничений, повторные правки и дополнительные проверки. Сопоставление этих затрат помогает определить, какие доработки принесут больше пользы.
Отчеты анализаторов кода дополняют оценку, однако количество найденных замечаний само по себе не показывает, насколько сильно техдолг мешает разработке. Такие расчеты остаются приблизительными. Ожидаемая экономия зависит от того, как часто команда будет менять соответствующий участок системы и какие задачи ей предстоит решать.
Где и зачем учитывают технический долг
Его учитывают при разработке и поддержке сайтов, мобильных приложений и корпоративных систем. Оценка его последствий помогает разработчикам и руководителям понять, как состояние продукта влияет на сроки и стоимость дальнейшей работы. Учет техдолга помогает решать несколько задач.
Планирование сроков разработки
Добавление новой функции может потребовать предварительной доработки существующего кода. Например, перед расширением системы скидок в интернет-магазине команда может решить объединить несколько версий расчета. Если учесть эту работу заранее, команда сможет точнее оценить сроки и включить необходимые технические задачи в план выпуска.
Выбор того, какие участки кода дорабатывать первыми
Оценка техдолга помогает определить, где изменения принесут больше пользы. Если команда регулярно работает с одним и тем же модулем и каждый раз тратит время на обход его ограничений, переработка может заметно упростить следующие задачи. Поэтому при выборе приоритетов учитывают, как часто приходится менять этот код и насколько он мешает развитию продукта.
Обоснование необходимости технических работ перед бизнесом
Результат переработки кода не всегда заметен пользователям, поэтому команде важно объяснить, зачем выделять на нее время и бюджет. Учет техдолга помогает связать такую работу с конкретными последствиями — сокращением времени на доработки, упрощением проверок или снижением риска ошибок. Это дает разработчикам и руководителям основу для обсуждения расходов и приоритетов.
Оценка последствий быстрого запуска
Когда команда выбирает временное решение ради ближайшего релиза, полезно заранее понять, какую дополнительную работу оно создаст в будущем. Такая оценка помогает сопоставить пользу раннего выпуска с затратами на последующие изменения. На этой основе можно решить, оправдан ли компромисс и при каких условиях к нему нужно вернуться.
Преимущества и ограничения работы с техдолгом
Работа с техническим долгом может сократить затраты на поддержку продукта и упростить выпуск новых функций. При этом на поиск проблем, переработку кода и проверку изменений тоже нужны время и ресурсы.
Преимущества
- Меньше повторяющейся работы. Когда команда устраняет запутанные связи между частями программы и упрощает ее структуру, разработчикам становится легче вносить изменения. Им реже приходится возвращаться к одним и тем же ограничениям и искать обходные решения. Особенно заметна польза в тех частях продукта, которые регулярно дорабатывают.
- Знания о проблемах доступны всей команде. Если причины временных решений и их последствия зафиксированы, разработчикам проще учитывать их в дальнейшей работе. Информация сохраняется при смене сотрудников, а новым участникам проекта легче понять, почему система устроена именно так и какие ограничения нужно принимать во внимание.
- Улучшения можно проводить постепенно. Часть технического долга удается сокращать в ходе обычной разработки. Например, перед добавлением функции можно упростить участок кода, который предстоит изменить. Такой подход позволяет совмещать технические улучшения с развитием продукта и проверять результат небольшими шагами.
Недостатки и ограничения
- Сам учет техдолга требует времени. Команде нужно описывать проблемы, оценивать их последствия и пересматривать приоритеты по мере изменения планов. Если собирать подробные сведения, которые затем не используются при принятии решений, ведение списка превращается в дополнительную нагрузку.
- Будущую экономию трудно рассчитать точно. Разработчики могут оценить, сколько времени займет переделка, но заранее определить, насколько она ускорит выполнение следующих задач, сложнее. Это зависит от будущих требований и частоты изменений в конкретной части системы. Поэтому расчеты помогают сравнивать варианты, но не гарантируют, что затраты окупятся в ожидаемый срок.
- Переработка кода может привести к новым ошибкам. Даже если задача состоит только в улучшении внутреннего устройства программы, изменения могут затронуть ее поведение. Поэтому в объем работ нужно включать проверку существующих функций. Небольшие последовательные изменения и регулярное тестирование помогают снизить этот риск.
Типичные ошибки и некорректные ожидания новичков
Считать техдолгом любой старый или непривычный код
Возраст кода и незнакомый стиль сами по себе не означают, что программу нужно переделывать. Сначала стоит разобраться, почему разработчики выбрали такое решение и какие трудности оно создает сейчас. Основанием для доработки могут быть конкретные последствия — например, необходимость менять несколько частей системы ради одной небольшой функции.
Ожидать, что переписывание проекта решит все проблемы
При создании новой версии нужно разобраться в поведении существующей системы, сохранить нужные функции и учесть ее связи с другими сервисами. Эта работа может оказаться сложнее, чем кажется при первом знакомстве с кодом. Поэтому решение о полном переписывании стоит принимать после оценки затрат, рисков и возможности заменить отдельные части продукта постепенно.
Ставить задачи без понятного результата
Общая просьба «улучшить код» не объясняет, какую проблему нужно решить и когда работа будет закончена. В задаче стоит указать, где возникает трудность, как она влияет на разработку и по каким признакам команда поймет, что ее удалось устранить. Это помогает определить объем работ и проверить пользу изменений.
Полагаться только на отчет анализатора
Программа для автоматической проверки кода находит проблемы по заданным правилам. Количество замечаний в отчете не показывает, какие из них сильнее мешают работе команды, а часть ограничений может остаться незамеченной. Поэтому результаты проверки нужно дополнять разбором устройства системы и трудностей, с которыми разработчики сталкиваются при выполнении задач.
Объединять разные изменения в одну большую правку
Рефакторинг предполагает изменение внутреннего устройства кода с сохранением наблюдаемого поведения программы. Если одновременно перестраивать модуль и добавлять в него новую функциональность, при проверке будет сложнее отличить запланированные изменения от случайных ошибок. Такую работу удобнее разделять на небольшие последовательные шаги, результат каждого из которых можно проверить отдельно.
Рассчитывать, что от техдолга можно избавиться навсегда
По мере развития продукта меняются требования, а команда лучше понимает задачи и ограничения системы. Поэтому даже удачное решение со временем может потребовать пересмотра. Результат работы с техдолгом разумнее оценивать по тому, удалось ли устранить конкретные трудности и упростить дальнейшие изменения в продукте.
Самое важное о техническом долге
- Технический долг — это недостатки в коде и структуре системы, которые усложняют поддержку и развитие продукта. Для пользователя все может работать исправно, но разработчикам приходится тратить больше времени на изменения.
- Команда может сознательно отложить доработки ради быстрого запуска. Иногда ограничения выбранного решения становятся понятны уже в ходе работы, поэтому техдолг возникает даже у опытных разработчиков.
- Один из способов оценить долг — сопоставить затраты на его устранение с дополнительной работой, которую он создает. Отчеты анализаторов кода помогают выявлять проблемы, но не отражают всех трудностей, с которыми сталкивается команда.
- В первую очередь имеет смысл устранять проблемы, которые регулярно замедляют разработку или мешают запланированным изменениям. Это позволяет связать технические доработки с конкретными задачами продукта.
- Сокращать долг можно постепенно, улучшая отдельные участки кода. Такие изменения тоже могут привести к ошибкам, поэтому при планировании нужно учитывать время на проверку.
- Полное переписывание системы не гарантирует избавления от техдолга: по мере развития продукта могут обнаруживаться новые ограничения. Пользу доработок оценивают по тому, насколько проще стало вносить изменения и сколько лишней работы удалось сократить.
