Расчет технологического долга: на основе скорости против. Основанный на проблеме против. Объяснение измерений, основанных на качестве

10 февраля 2023 г.

Процентные ставки увеличились на 157%!

Нет, я говорю не о последнем решении ФРС, а о замедлении, с которым столкнулась Fictional Inc. после выпуска версии 3.0 своей платформы.

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

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

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

Хорошо, вы, вероятно, не услышите, чтобы технический менеджер так говорил о своем техническом долге.

Но почему нет?

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

<цитата>

Когда мы думаем о техническом долге, проценты — это количество времени, потерянного на текущую и будущую разработку по сравнению с существующим уровнем технического долга.

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

Каков нормальный уровень технического долга?

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

Сразу же возникает одна очевидная проблема: основная сумма — это фиксированная единица времени (часы исправления/перезаписи), а процент — это количество часов, потерянных за это время. Чтобы объяснить это, нам нужно ввести понятие интервал воздействия — время, в течение которого мы заботимся о том, превышают ли будущие замедления из-за технического долга стоимость перезаписи. Интервал воздействия, о котором вы заботитесь, будет сильно зависеть от вашей компании, вашего типичного процесса планирования и его стадии или жизненного цикла вашей кодовой базы, но лично я обычно рассматриваю интервал воздействия в 3 месяца. На начальном этапе нашей компании рассматривать что-либо в масштабе год + сроки слишком широко, но что-либо короче, чем 2–3 месяца, будет сильно недооценивать влияние технического долга, как мы увидим позже.

Это означает, что наш уровень технического долга не стоит решать, если:

n

Например, если бы у нас был небольшой проект, о котором мы знали, что у него есть технический долг, который замедлял работу на 2 часа в неделю, нам потребовалось бы 4 дня на рефакторинг этого долга. еще не потратил бы время, чтобы погасить этот долг.

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

Как мы измеряем технический долг?

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

Измерение на основе скорости

Самый прямой способ связать замедление с различными разделами нашей кодовой базы – это посмотреть, как скорость меняется со временем в разных разделах вашего проекта. Просматривая различные области кодовой базы, вы можете начать выявлять вариации (например, любая разработка, касающаяся этого раздела анализа, занимает в 3 раза больше времени, чем что-либо еще) в разных разделах. Глядя на изменение области с течением времени, вы также можете получить некоторое представление о том, как новая разработка повлияла на темпы будущей разработки, и дает представление об уровне интереса, которым занимается ваша команда.

Например: если у нас есть относительно простой проект с 4 различными областями, над которыми мы будем работать, мы можем посмотреть, как скорость меняется с течением времени (здесь мы отслеживаем скорость в пунктах истории/месяце разработки).

Измерение влияния технического долга на основе скорости

Отсюда мы можем видеть, что работа над D всегда занимала примерно в 3 раза больше времени, чем над любой другой областью для аналогичных сложных задач. Это означает, что он представляет в 3 раза больше интереса, чем все остальные разделы кодовой базы. Раньше B был относительно на одном уровне с A & C, но, начиная с 4-го месяца, он внезапно подскочил и занял в 2 раза больше времени. Это говорит о том, что мы ввели здесь некоторый долг, который удвоил нашу процентную ставку по сравнению с тем, что было раньше для B.

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

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

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

Одним из быстрых способов измерения на основе скорости является запрос вашей команды инженеров относительно того, сколько времени требуется для завершения проекта/задачи в каждой основной области вашей кодовой базы. Согласуйте некоторый установленный базовый уровень для хорошо изученной/часто используемой области, а затем попросите всех оценить друг друга в процентах или кратных этому базовому уровню. Хотя он и не такой строгий, как подход к измерению на основе полной скорости, он может дать быстрое представление о ваших относительных процентах по техническому долгу на основе понимания и интуиции вашей команды.

Измерение на основе проблем

Другой подход заключается в выявлении конкретных случаев технического долга в вашем проекте и оценке того, насколько каждый из них может замедлять работу. Частично это можно сделать с помощью автоматизированных инструментов, таких как инструменты статического анализа, чтобы найти общие проблемы с качеством кода, которые могут повлиять на удобочитаемость, расширяемость или ремонтопригодность проекта. Для каждого типа проблемы вы можете назначить процентную ставку (например, 5 минут в неделю или 1%) в зависимости от опыта вашей команды в решении таких проблем.

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

Некоторые из недостатков этого подхода:

• Оценки времени, связанные с конкретными проблемами, могут быть неточными.
• Некоторые проблемы могут оставаться незамеченными в течение длительного периода времени.

Оценка качества

Существует множество показателей качества кода, которые вы можете использовать, чтобы получить общее представление о состоянии вашей кодовой базы и, в свою очередь, оценить, насколько ваш текущий технический долг влияет на будущее развитие в каждой области. В Sourcery мы обычно обращаем внимание на сложность, Рабочая память и длина метода в качестве критических показателей при просмотре внутри функции или класса, но вы также можете посмотреть на такие вещи, как индекс ремонтопригодности , Док & Тестовое покрытие, коэффициент дублирования и многое другое.

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

Рассмотрим пример. Давайте вернемся к простой кодовой базе из 4 частей, которую мы рассмотрели в разделе, посвященном измерению скорости.

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

Вот некоторые из недостатков этого подхода:

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

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

Анализ частоты взаимодействия с кодовой базой

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

Чтобы учесть это, нам нужно посмотреть, как часто вносят свой вклад в каждую область нашего проекта. Здесь мы можем использовать несколько разных подходов: просмотр истории Git, чтобы понять, какая область затрагивается чаще всего, с использованием более целенаправленных инструментов, таких как Codescene. , чтобы получить более удобоваримые исторические данные о вкладе, или использовать перспективный подход, изучив наши предстоящие планы и приоритеты, чтобы понять, где наша команда будет проводить большую часть своего времени в течение следующих нескольких месяцев.

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

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

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

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

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

Управление процентами и долгом

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

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

Как мы обсуждали ранее, обычно мы не хотим тратить время на изучение областей кодовой базы, где:

Но в крайнем случае мы можем столкнуться со случаем, когда мы сильно замедляемся из-за высокого уровня долга, который чрезвычайно дорого исправить, что тоже не очень хорошая ситуация.

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

н

---

Оригинал