Итак, технический долг — это известная фраза, она настолько часто используется, что иногда кажется, что разработчики используют ее, когда им лень объяснять что-то, что им нужно сделать. Но что это? Что вызывает это? Можем ли мы этого избежать? Нужно ли нам избегать этого? Как мы можем погасить наши долги разумным способом?
Давайте рассмотрим эти вопросы, чтобы мы могли найти решение, которое работает для нас в течение последних нескольких лет.

Что такое технический долг?

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

Почему мы делаем это с собой?

Две наиболее распространенные причины технических долгов, которые я видел:

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

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

Можем ли и должны ли мы избежать технического долга?

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

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

Да, мы много писали о техдолгах, но это звучит не так страшно — где переломный момент?

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

  1. Ошибки — мы заботимся о качестве нашего продукта, поэтому обычно внимательно следим за показателями ошибок. Как только вы видите, что эти графики растут, и вы видите, что большая часть вашего времени уходит на отладку, вы понимаете, что нужно что-то менять.
  2. Скорость — наступает момент, когда все ярлыки, вызывающие скорость, накапливаются до полной остановки. Каждая часть новой логики слишком сложна. Есть слоновьи кладбища кода, к которым нас учат никогда не приближаться, и мы слышим предложения вроде: «О, этот компонент? Каждый раз, когда мы его касаемся, это как минимум 2 дня работы» при оценке задач.

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

Итак, что нам делать?

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

  1. Ясность — хотя погашение технического долга обычно является «закулисной» задачей, то есть — не меняйте бизнес-логику, убедитесь, что ваши коллеги хорошо осведомлены о том, над чем вы работаете и почему! Это действительно помогает укрепить доверие и убедиться, что никто не занимается разработкой ради упражнения, а для того, чтобы сделать X, Y, Z (уменьшить количество ошибок в определенном месте, сократить время разработки в определенном месте). конкретное местоположение и т. д.) — эти точки данных можно легко извлечь из Jira.
  2. Измерение — пометьте эти проблемы по-другому! таким образом вы можете узнать процент времени, который каждый раз посвящает техническому долгу, а не новой функции.
  3. Устанавливайте ожидания с бизнесом — здесь вам нужно провести обсуждение в выдуманном масштабе того, где организация должна быть в битве между быстрым ‹› качеством. Эта шкала позволит вам решить, сколько времени вы хотите потратить на технический долг.

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

40% — технические, 40% — фичи, 20% — баги.

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

Спасибо Антону Друху за помощь в преодолении сложных инженерных вод. Многие из наших повседневных практик основаны на его наставничестве.