Два вида технического долга и их погашение

Перевод статьи Кайла Галбрайта «Two Kinds of Tech Debt and How to Pay It Down».

Технический долг

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

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

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

Краткий пример технического долга

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

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

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

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

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

Долг итеративной разработки

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

Но мы работаем не в идеальном мире.

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

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

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

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

Долг итеративной разработки

Как с этим справиться?

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

  • Мы можем добавлять комментарии TODO к функциям, которые, как мы знаем, должны быть пересмотрены. Также должна быть процедура их пересмотра при работе с багами или новым функционалом в этой зоне.
  • Если технический долг был представлен в ходе разработки пункта из бэклога, можно добавить в тот же бэклог связанный с долгом пункт, чтобы произвести пересмотр в будущем.
  • Будет полезным проведение регулярных собраний, посвященных расстановке приоритетов в техническом долге. Разработка ПО это создание надежного продукта для наших конечных пользователей, а исправление/чистка технического долга связана с обеспечением надежности.

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

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

Долг повторяющихся задач

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

Как же он обнаруживает себя?

Мы ищем вещи, которые нас тормозят. У нас есть задачи, которые мы вынуждены выполнять вручную 2-3 раза в неделю? Нам приходится снова и снова отвечать на одни и те же вопросы? И то, и другое можно рассматривать как технический долг.

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

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

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

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

Заключение

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

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

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


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх