В третьем эпизоде программы «От теории к практике» к Мэтту Дэвису и Курту Андерсену из Blameless присоединились Лиз Фонг-Джонс из Honeycomb.io и Жан Клермонт из Flatiron, чтобы обсудить два слова, которых боится каждый инженер: технический долг. Что же такое технический долг? Даже если вы не слышали этот термин, я уверен, что вы сталкивались с ним: части вашей системы, которые остались неисправленными или не совсем соответствуют требованиям, но ни у кого, похоже, нет времени, чтобы работать над ними.
Представьте, что ваша программная система — это дом. Технический долг — это течь в раковине, которую вы еще не успели починить. Технический долг — это беспорядок в офисе, который вы давно не наводили. Это также новая полка, которую вы купили, но еще не установили. Со временем количество дел быстро накапливается. Даже если некоторые задачи решаются быстро, их становится так много, что трудно понять, с чего начать.
По мере того, как программные системы становятся все более сложными, с большим количеством интеграций, микросервисов и функций, возрастает вероятность накопления технического долга. Как опередить его, пока он не накопился? И как справиться с уже имеющимся техническим долгом, не снижая скорости работы над новыми проектами?
С этим вопросом сталкивается каждый инженер. Мы были рады пригласить двух экспертов для обсуждения этого вопроса. Лиз Фонг-Джонс — SRE с 16-летним опытом работы в области повышения надежности социотехнических систем. Она видела широкий спектр технических долгов, начиная с проблем, с которыми сталкиваются быстро развивающиеся стартапы, избегающие накопления технических долгов, и заканчивая выплатой технических долгов, накопленных годами в крупных корпоративных организациях. Жан Клермон — руководитель программы в компании Flatiron, специализирующейся на медицинских технологиях. Управление инцидентами и создание устойчивости к внешним воздействиям при работе с таким критическим явлением, как человеческое тело, требует проактивного мышления для решения долгосрочных проблем, включая технологический долг.
Посмотрите запись, чтобы услышать их мнение. И, как я это делал в первом и втором эпизодах, я подытожу три ключевых момента из их обсуждения!
Выплатить технический долг — значит действительно знать, где он находится
Бывает трудно отследить, где накапливается технический долг. Даже если у вас есть возможность активно сокращать технический долг, как понять, что нужно делать в первую очередь? Это вопрос, на который нужно ответить как проактивно, так и реактивно.
При проактивном подходе вы должны стараться регистрировать технический долг по мере его возникновения. Иногда технический долг неизбежен. Вам может понадобиться внедрить исправление или функцию, для поддержания которой требуется трудоемкий процесс, или она неинтуитивно понятна при расширении. Мэтт советует регистрировать все изменения, которые создают такие проблемы. Таким образом, когда вы захотите сократить технический долг, у вас будет готовый список проблем, которые необходимо решить. Вы также можете использовать этот список при оценке того, сколько времени займут будущие задачи и обновления — вы сможете компенсировать задержки, которые вызовет технический долг при работе в определенных областях кодовой базы. Оценка этих задержек может мотивировать вас на устранение наиболее вредного технического долга.
Лиз отметила, что сосредоточенность исключительно на «известном» техническом долге может «убаюкать вас ложным чувством безопасности». Многие технические долги создаются незаметно для людей, в результате небольших решений, которые имеют неожиданные последствия. Жан описал технологический долг как «айсберг», подавляющая часть которого может быть скрыта под поверхностью. Столкновение с этим неизвестным техническим долгом, скорее всего, будет еще более разрушительным, чем ожидаемый технический долг, поскольку вы не сможете проактивно компенсировать его.
Как же найти этот технический долг «под поверхностью»? Нужно искать его симптомы. Лиз выделяет два основных способа проявления технического долга: усложнение разработки нового программного обеспечения и увеличение трудозатрат на обслуживание системы. Обратите внимание на общие процессы, которые очень утомительны, или пересмотрите проекты, которые сталкиваются с множеством неожиданных препятствий. Возможно, причина кроется в техническом долге.
Лучше всего выплачивать технический долг постепенно.
Может возникнуть соблазн сделать заявление типа «мы потратим время до конца квартала, чтобы разобраться со всеми нашими техническими долгами, а потом все будет в порядке». Точно так же люди ведут себя по отношению к финансовым долгам или другим задачам, которых они избегают. Вместо того чтобы решать их по мере возникновения, человек представляет себе, что в будущем появится совершенно другое отношение или возможность, которая позволит легко справиться с запущенными задачами.
К сожалению, этот план обычно не срабатывает. Если у вас нет привычки постоянно работать с техническим долгом, то переключение на него будет резким и ограничит продуктивность. Скорее всего, вы не сможете понять, с чего начать погашение технического долга, если обычно игнорируете его. Более того, вы сразу же начнете накапливать технический долг снова, не имея привычки отслеживать его и справляться с ним.
Вместо этого решайте проблему технического долга постепенно, устраняя мелкие детали по мере их обнаружения. Лиз предложила инженерам, работающим по вызову, найти возможность вложить средства в борьбу с техническим долгом. Работа над документацией и руководствами может помочь справиться с техническим долгом. Даже если у вас нет возможности пересмотреть сам код, наличие документации и процессов уменьшит количество проблем, вызываемых техническим долгом. Она также покажет, на что следует потратить усилия, чтобы внести фундаментальные изменения, когда это возможно. Каждый шаг, который вы предпринимаете для сокращения технического долга, помогает больше, чем ожидание идеального момента для того, чтобы попытаться уничтожить его полностью.
Стимулируйте работу с техническим долгом
Погашение технического долга — не всегда самая гламурная и заметная работа. К сожалению, по сравнению с разработкой новых функций, которые становятся знаменитыми релизами, очистка или документирование старого кода может не получить такого же признания. Вместо того чтобы пытаться игнорировать это несоответствие между видами работ и надеяться, что люди справятся с проблемой технического долга независимо от этого, попробуйте найти способы сделать работу с техническим долгом более известной.
Один из вариантов, предложенный Мэттом Дэвисом, заключается в создании программ типа «bug bounties» для проблемных частей технического долга. Тот, кто найдет время и энергию для исправления технического долга, сможет претендовать на вознаграждение. Это вознаграждение может быть реальным финансовым вознаграждением или признанием на общекомандном или общеорганизационном собрании.
Другой вариант — добавить устранение технического долга в требования к спринтам и проектам наряду с работой над новыми функциями. Например, план проекта может включать три новые функции и одну крупную часть технического долга. Такой план, предложенный Куртом, ставит техническую задолженность на один уровень с разработкой функций, в равной степени способствуя завершению проекта. Это помогает работе получить признание, поскольку она отслеживается наряду с остальной работой над новыми функциями.