Программист живёт от дедлайна до дедлайна и завал — обычное явление. Он пытается выполнить максимум задач, зачастую опуская некоторые моменты «на потом». Этот «потом» у многих не наступает никогда (ведь появляются всё новые и новые задачи) и некачественный код живёт своей жизнью, тая потенциальные проблемы. Наш подписчик решил вырваться из этого порочного круга и задал вопрос:
«Как научиться не накапливать технический долг?»
За разъяснениями мы обратились к нашим экспертам, а полученные ответы предоставляем вашему вниманию.
Смотрите также: Пьеса «Технический долг»: типичный случай из жизни разработчика
Чудесных рецептов и секретов здесь нет — нужно на регулярной основе выделять (выгрызать, если вы работаете в корпоративной среде) время и избавляться от технического долга.
Выглядеть это может как угодно, например, включаете задачи по устранению долга в бэклог наравне с бизнес-задачами, форма не принципиальна — главное, чтобы работало.
Помогут здесь в первую очередь:
- Авто-тесты, их обязательно нужно писать, иначе всё превратится в «переписали код как положено, но теперь продукт вдруг перестал работать как надо»;
- Логическое (и физическое) разбиение приложения на сервисы с чётко обозначенными границами ответственности. Таким образом, технический долг можно будет устранять в каждом сервисе (не затрагивая остальные).
Добавлю лишь, что иногда в качестве инструмента «принуждения» к выделению времени на устранение долга используется подход, при котором разработчики не заморачиваются с техническим долгом до тех пор, пока продукт становится полностью неподдерживаемым. После чего с большим количеством конфликтов принимается решение «переписать всё» и все заинтересованные стороны (заказчик, руководство и команда) убеждаются в необходимости выделения времени на устранение технического долга.
Способ достаточно конфликтный и жёсткий, если не сказать жестокий, поэтому я не рекомендую его использовать на практике.
На тему технического долга вскоре можно будет писать книги. По сути, это тема управления продуктом. Из названия ясно, что это что-то, оставленное на потом. В нашем случае это работа, программирование. Избежать этого достаточно сложно. Вот пример: сайт для заказчика. Обычно никто не жертвует front-end, так как это имидж компании. Экономят на back-end, безопасности. Оставляют на потом, когда будут деньги. Здесь важно грамотно выстроить процесс разработки, а это задача руководителя проекта или команды. Вот грубый цикл разработки: идея — макет — архитектура — прототип — alpha — beta — тестирование — релиз. Чем действительно можно пожертвовать, а чем нет?
С моей точки зрения, 3 решения:
1) Если долг не мешает процессу, то просто его опустить.
2) Перестать балансировать между качеством и скоростью, а выбрать один параметр.
3) Нанять человека: архитектора, планировщика. Чтобы он правильно оценил пункты, которые можно вынести на будущие версии. То есть он должен с ходу хотя бы приблизительно представлять, какая функциональность в какие даты и в какой версии должна (!) быть реализована.
Однако технический долг — это не те вещи, которые стоит обходить (у всех разное финансирование). Это работает и как дополнительный стимул.
Говоря о техническом долге, необходимо различать личное желание разработчика улучшить некоторые места в коде и реальную необходимость оптимизации или рефакторинга, чтобы избежать дальнейших проблем при расширении и изменении функциональности. Эта необходимость обычно возникает, если разработчик не успевает в срок сделать фичу и «лепит» что получится, лишь бы сейчас заработало и прошло тестирование.
Технический долг обычно возникает по одной из двух причин:
1. Недостаток опыта у разработчика. Решение простое – набирать этот опыт, заполнять пробелы в знаниях, пользоваться помощью более квалифицированных коллег.
2. Неверно выбранный способ реализации. Это опасная ошибка, которая говорит о неправильно построенном процессе. Если за написание кода всегда хвататься с горящими глазами, не обдумав всё от и до, не рассмотрев все кейсы и не задав все вопросы, то в скором времени блокнот с техническим долгом разрастётся так, что можно будет половину программы писать с нуля.
Поэтому, чтобы сократить накопление технического долга, нужно выработать в себе привычку вначале погрузиться в задачу, уточнить всё, что можно, изучить все тест-кейсы, определить для себя план на листочке, а только потом садиться за написание кода. Тогда процесс займёт меньше времени, количество багов сократится, и заранее будет выбран самый оптимальный способ реализации фичи. К тому же в процессе уточнений требования могут измениться, и вам не придётся тратить время на изменение кода и «впиливать» в него новые условия.
Ни одна лучшая практика не будет работать эффективно, пока не будет соблюден ряд условий:
Перестать называть плохой код техническим долгом
Часто техническим долгом называют разработку спустя рукава. Первый шаг — политика абсолютной нетерпимости к незапланированной порче кодовой базы.
Создавать технический долг осознанно
Технический долг — мощный инструмент, в умелых руках. Тщательно запланируйте его возврат: «просто порефакторим в следующем спринте» — не план, а оправдание.
Объяснить термин коллегам из нетехнических областей
Самый важный и, вероятно, самый сложный шаг — коммуникация. Без поддержки людей, принимающих решения, вас просто заставят набрать долгов и оставят разгребать последствия в одиночку.
Не бойтесь погрузить менее технически подкованных коллег в проблематику: ваши менеджеры оценят подробно рассчитанный ROI и анализ рисков, дайте коллегам почитать The Software Project Survival Guide Макконнелла и познакомьте с релевантными исследованиями, пригласите на несколько ретроспектив и планерок, покажите результаты работы ваших статических анализаторов, в конце концов.
Научитесь защищать свой код не только перед командой разработки, но и перед бизнесом — начните воевать в одну сторону, и контроль технического долга перестанет вызывать панику в обоих лагерях.
Последние десятилетия мы живём в парадигме, где time to market имеет первостепенное значение. Очень может статься, что к тому времени, когда ваша команда закончит работу над вашим шедевром, на рынке уже не останется устройств, где его можно будет запустить. А это означает, что технический долг — это норма наших дней. Нам, программистам, есть чему поучиться у финансистов. Давайте не будем называть это «долгом». Давайте назовём это… техническим кредитом. И будем управлять им подобно тому, как финансисты используют свои финансовые инструменты.
В продуктовой разработке скорость доставки изменений — одна из основных метрик. При этом описать будущую архитектуру проекта в начале работы зачастую невозможно. Поэтому накопление технического долга — процесс естественный и неизбежный, но при соблюдении некоторых правил вполне решаемый.
Во-первых, накопление долга нужно брать под контроль: заведите в вашем таск-трекере специальный раздел (доску, тег, тип задачи), чтобы задачи по техническому долгу можно было оценивать, планировать и приоритизировать точно так же, как любые другие. За ведение такого бэклога по техническому долгу обычно отвечает тимлид или техлид команды.
Во-вторых, о необходимости таких работ лучше заранее договариваться со всеми, в первую очередь с продакт-менеджерами и заказчиками. Часто это самый сложный момент, так как нужно их убедить потратить драгоценное время разработчиков не на новые продуктовые фичи, которые помогут обогнать конкурентов, а на непонятную на первый взгляд деятельность без очевидного результата. В моей практике лучшим аргументом был постоянно увеличивающийся срок реализации простых с виду задач — разработчики знали, сколько сложных мест в коде им придётся обойти, сколько новых костылей расставить, и закладывали эти параметры в общую оценку задачи. После нескольких таких планирований продакт-менеджеры сами предлагали команде взять задачи на рефакторинг.
В-третьих, работы по техническому долгу — это как уборка. Для обеспечения чистоты нужна регулярность. В зависимости от того, как устроен ваш процесс, вы можете брать по одной такой задаче в спринт или делать субботники раз в месяц, но затягивать с уборкой не стоит — ведь гораздо проще раз в неделю протереть пыль, чем раз в год целую неделю драить всю квартиру.
В-четвёртых, не забывайте про метрики в ваших приложениях, которые помогут выявить технические проблемы там, где их не видно при простом взгляде на код: измеряйте производительность запросов и рендеринга; профилируйте запутанные места, чтобы понять, действительно ли там есть проблемы; не пренебрегайте статическими анализаторами для выявления ошибок и избыточной сложности.
А главное, любите и уважайте ваш технический долг. Ведь если он не накапливается, значит ваш проект перестал развиваться.
Технический долг — это не баг или криво написанный код, а умышленное пренебрежение качеством кода, и иногда просто не избежать момента, когда нужно написать «быстро и чтоб это заработало прямо сейчас».
Первое, что можно посоветовать в этом вопросе, — никогда не замалчивайте технический долг. Если вам приходится умышленно писать «плохо», этого не надо стесняться и это обязательно нужно открыто обговаривать с другими участниками проекта.
Я для себя такие «плохие» участки программы разделяю на два типа: то, что будет запущено только один раз, и что-то вроде прототипа, что нужно быстро запустить и посмотреть, как это «полетит». Для первого всё просто: сразу после использования этот участок нужно почистить, притом незамедлительно. Если не решить эту проблему сразу, потом уже точно времени на это не будет и некачественный участок придётся поддерживать постоянно. Со вторым случаем чуть сложнее, ведь можно подумать: «Всё работает, зачем делать что-то ещё?» Тут уже вопрос вашей собственной дисциплины.
Как с этим справляться? Если вы понимаете, что возникновения технического долга не избежать, лучше подготовиться к этому заранее — то есть заложить время на доработку этого участка. Предупредите менеджеров о ситуации и заведите сразу два тикета с одинаковыми приоритетами — на разработку фичи и на исправление технического долга.
Технический долг — это бич любой программной разработки. Часто «хорошо бы сделать, но отложим на потом» со временем превращается в неразрешимый ком проблем.
Мы работает по Scrum. Состав бэклогов команды и спринта контролируют руководитель проектов и тимлид команды, длительность спринта составляет две недели. Все задачи разработки делятся на три типа:
- Продуктовые — это разработка решений бизнес-задач, как правило, эти задачи выполняются в рамках проектов;
- Поддержка — задачи-сопровождения существующих продуктов, внесение незначительных исправлений в логику работы;
- Архитектурные — это как раз и есть задачи технического долга. В их состав входят и задачи технического долга разработки функциональности бизнес-продуктов, и общий техдолг;
В каждом спринте для каждого из типов задач выделяется своя квота времени, которая учитывается при планировании:
- Продуктовые задачи — 70% времени длительности спринта.
- Поддержка — 20%.
- Архитектурные — 10%.
После завершения крупных проектов команда разработки совместно с руководителем проектов своего направления планирует и организует технический спринт, цель — устранить наиболее критичные задачи технического долга, которые появились в ходе выполнения проекта.
Но бывает необходимость решения сложных задач, которые по трудоёмкости далеко превышают рамки квот архитектурных задач в спринтах и длительность технических спринтов. В этом случае инициируется архитектурный проект. Лидером проекта становится один из технических лидеров разработки. Проект оценивается с точки зрения затрат и выгод для бизнеса и приоритизируется наряду с проектами по разработке бизнес-решений.
Последнее и немаловажное мероприятие — актуализация бэклога задач технического долга.
В нашей компании задачи технического долга ведутся в отдельном проекте JIRA и отображаются и в бэклогах команд разработки, и в бэклоге отдела разработки. Таким образом, за актуальностью задач техдолга следят и руководители проекта с тимлидами команд, и линейные руководители разработки. Это позволяет отслеживать и закрывать задачи, которые либо перестали быть актуальными, либо решены в рамках других задач.
Резюмируя всё вышесказанное, для успешной борьбы с техническим долгом используются следующие приёмы:
- 10% времени спринта тратится на задачи технического долга;
- по завершении крупного проекта следует технический спринт;
- в случае необходимости внедрения крупных технических изменений инициируется архитектурный проект;
- бэклог технического долга всегда находится в актуальном состоянии, за этим следят и команды разработки, и линейные руководители разработки.
Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.
