Привет, Хабр! Хотел бы поделиться с вами своим анализом работы с техническим долгом.

Технический долг (также известный как долг кодинга) — это метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.

Как появился этот долг? Мы его взяли что бы поставить заказчику функционал раньше, чем мы бы смогли, если бы не "заняли". Так же как бизнесмен берет кредит для своей бизнес идеи.

???? Экстремальное программирование — это пример разработки с кредитом качества

Проценты выплачиваются при выполнении задач. Многие встречали ситуацию когда продукт‑менеджер говорит: «Да тут небольшое изменение внести”, а разработчик пытается объяснить что там кривая архитектура и вообще все на костылях держится и нужен месяц на такую фичу. Разница между работой над конкретной фичей и реальными затратами с учетом костылей, является наш процент. И он постоянно растет, если не оплачивать основной долг.

Технический долг (ТД) как глыба льда под водой, невидимая для бизнеса. И цель разработчиков эту глыбу показать и устранить.

Не следует яро стремиться к полному погашению долга. Необходимо уметь правильно оценивать свою «финансовую» нагрузку и не брать на себя больше обязательств, чем способен исполнить. «Если кинуть все силы на долг, то можно остаться без дохода и обанкротиться».

Варианты технического долга

• ????Осознанный: осознанные компромиссные решения и костыли.

• ????Неосознанный: отсутствие стандартов, отсутствие контроля чистоты кодовой базы, неосознанные костыли.

????Как уменьшить основной долг

• Для начала нужно избавиться от неосознанных кредитов:
  

  • Развиваем команду

  • Внедряем стандарты написания кода

  • Проводим Code Review

• Ставим задачи на приоритеты

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

• Встречаем сопротивление

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

  Предусматривайте ресурсы для работы с ТД. Самая распространённая модель — это 70% для обычной работы, 20% для технического долга и 10% для обучения/экспериментов.

  Проблема здесь кроется в том, что крупные проблемы с техническим долгом никогда не решаются всего за 20% времени. Их переносят от спринта к спринту, в ходе переноса теряется контекст, и добиться нужного результата становится труднее. Ещё одна сложность заключается в невозможности соблюдения точных временных рамок при решении разных задач.

• Проводим “Реструктуризацию” технического долга

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

⚖️Инкрементный рефакторинг

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

Контролируемый — подразумевает итерационный процесс улучшения.

???? «Всегда оставляйте лагерь чище, чем он был до вас»

Делаем перевес в выплату основного долга вместо процентов. При планировании задач выделяем сразу работы по мелкому рефакторингу если в задаче есть пересечение с ТД. Важно сохранить общие сроки задачи, тогда бизнесу не следует даже говорить о тех долге. Если сроки увеличиваются, то придется согласовывать работы и отгрызать каждый час работ. Из-за декомпозиции ТД отклонения будут не большие и шанс аргументировать будет больше, чем при полномасштабном рефакторинге.

70/20 - из описания выше мы знаем 70% для обычной работы, 20% для технического долга и 10% для обучения/экспериментов. В случаи постепенного рефакторинга, 20% это будет буфер отклонения от бизнес задачи. Т.е. это то время на которое мы можем отклониться от сроков задачи в пользу устранения ТД. Эта модель может быть дикая по отношению к бизнесу, поэтому используйте ее с опаской.

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

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

Т. е. не следует тратить на рефакторинг много времени. Необходимо получить максимальную выгоду и вовремя остановиться.

????Подведем итоги

• Технический долг - это не плохо, но если он осознанный

• Долг необходимо держать в умеренном количестве

• Технический долг тоже требует приоритеты как и бизнес задачи

• Постепенный рефакторинг - это лучший способ работать с мелким технический долгом