Погасить технический долг, не обанкротившись в процессе.

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

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

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

Как узнать, какой у вас технический долг

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

Чтобы ответить на этот вопрос, мы задаем себе следующие вопросы:

  • Понятно, почему долг на месте?
  • Есть ли комментарии или документация по лучшему решению, реализация которого заняла бы больше времени?
  • Те же члены команды, которые создали долг в команде, исправляют долг?
  • Есть ли у вашей компании возможность позволить вам сосредоточиться на погашении долга?

Если вы ответили «нет» на что-либо из вышеперечисленного, ваш технический долг — это плохо. Если вы хотите узнать, насколько плохо, спросите себя, сколько раз вы отвечали «нет». Это не идеальная шкала, но это хорошая оценка.

Понравилась статья? Стань участником и подпишись, чтобы получать больше подобного контента!

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

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

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

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

Так как же нам избежать этого цикла?

Признайте, что работающий код всегда лучше, чем его отсутствие

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

Но это не значит жить с этим. Как бы мы ни признавали, что код «работает», мы не можем оставить его без ремонта.

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

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

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

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

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

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

Снежный ком долга

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

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

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

Снежный ком технического долга

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

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

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

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

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

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

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

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

Метод карманной раздачи

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

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

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

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

Что это означает для нашего технического долга? Это просто.

Код минимум, плюс немного

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

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

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

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

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

Понравилась ли вам эта статья? Стань участником и подготовь все, что пишет Трэвис Уэстон, а также все остальное, что доступно на Medium.

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