Техдолг: что сделать, чтобы коллекторы не пришли / Сергей Нечаев

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

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

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

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

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

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

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

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

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

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

Есть превратилось во внутреннюю систему, которую нельзя останавливать, выводить из эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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