Как научиться не накапливать технический долг — отвечают эксперты

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

«Как научиться не накапливать технический долг?»

За разъяснениями мы обратились к нашим экспертам, а полученные ответы предоставляем вашему вниманию.

Смотрите также: Пьеса «Технический долг»: типичный случай из жизни разработчика

Ильназ Гильязов

Ильназ Гильязов, эксперт курса «Профессия веб-разработчик» университета digital-профессий Нетология

Чудесных рецептов и секретов здесь нет — нужно на регулярной основе выделять (выгрызать, если вы работаете в корпоративной среде) время и избавляться от технического долга.

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

Помогут здесь в первую очередь:

  • Авто-тесты, их обязательно нужно писать, иначе всё превратится в «переписали код как положено, но теперь продукт вдруг перестал работать как надо»;
  • Логическое (и физическое) разбиение приложения на сервисы с чётко обозначенными границами ответственности. Таким образом, технический долг можно будет устранять в каждом сервисе (не затрагивая остальные).

Добавлю лишь, что иногда в качестве инструмента «принуждения» к выделению времени на устранение долга используется подход, при котором разработчики не заморачиваются с техническим долгом до тех пор, пока продукт становится полностью неподдерживаемым. После чего с большим количеством конфликтов принимается решение «переписать всё» и все заинтересованные стороны (заказчик, руководство и команда) убеждаются в необходимости выделения времени на устранение технического долга.

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

Сергиус Офицеров

Сергиус Офицеров, преподаватель HackerU

На тему технического долга вскоре можно будет писать книги. По сути, это тема управления продуктом. Из названия ясно, что это что-то, оставленное на потом. В нашем случае это работа, программирование. Избежать этого достаточно сложно. Вот пример: сайт для заказчика. Обычно никто не жертвует front-end, так как это имидж компании. Экономят на back-end, безопасности. Оставляют на потом, когда будут деньги. Здесь важно грамотно выстроить процесс разработки, а это задача руководителя проекта или команды. Вот грубый цикл разработки: идея — макет — архитектура — прототип — alpha — beta — тестирование — релиз. Чем действительно можно пожертвовать, а чем нет?

С моей точки зрения, 3 решения:
1) Если долг не мешает процессу, то просто его опустить.
2) Перестать балансировать между качеством и скоростью, а выбрать один параметр.
3) Нанять человека: архитектора, планировщика. Чтобы он правильно оценил пункты, которые можно вынести на будущие версии. То есть он должен с ходу хотя бы приблизительно представлять, какая функциональность в какие даты и в какой версии должна (!) быть реализована.

Однако технический долг — это не те вещи, которые стоит обходить (у всех разное финансирование). Это работает и как дополнительный стимул.

Дмитрий Тучин

Дмитрий Тучин, iOS разработчик Mediasoft

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

Технический долг обычно возникает по одной из двух причин:
1. Недостаток опыта у разработчика. Решение простое – набирать этот опыт, заполнять пробелы в знаниях, пользоваться помощью более квалифицированных коллег.
2. Неверно выбранный способ реализации. Это опасная ошибка, которая говорит о неправильно построенном процессе. Если за написание кода всегда хвататься с горящими глазами, не обдумав всё от и до, не рассмотрев все кейсы и не задав все вопросы, то в скором времени блокнот с техническим долгом разрастётся так, что можно будет половину программы писать с нуля.

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

Станислав Закрацкий

Станислав Закрацкий, руководитель группы разработки MAXIMUM (Head of R&D)

Ни одна лучшая практика не будет работать эффективно, пока не будет соблюден ряд условий:

Перестать называть плохой код техническим долгом

Часто техническим долгом называют разработку спустя рукава. Первый шаг — политика абсолютной нетерпимости к незапланированной порче кодовой базы.

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

Технический долг — мощный инструмент, в умелых руках. Тщательно запланируйте его возврат: «просто порефакторим в следующем спринте» — не план, а оправдание.

Объяснить термин коллегам из нетехнических областей

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

Не бойтесь погрузить менее технически подкованных коллег в проблематику: ваши менеджеры оценят подробно рассчитанный ROI и анализ рисков, дайте коллегам почитать The Software Project Survival Guide Макконнелла и познакомьте с релевантными исследованиями, пригласите на несколько ретроспектив и планерок, покажите результаты работы ваших статических анализаторов, в конце концов.

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

Михаил Жуков

Михаил Жуков, системный архитектор, Okko

Последние десятилетия мы живём в парадигме, где time to market имеет первостепенное значение. Очень может статься, что к тому времени, когда ваша команда закончит работу над вашим шедевром, на рынке уже не останется устройств, где его можно будет запустить. А это означает, что технический долг — это норма наших дней. Нам, программистам, есть чему поучиться у финансистов. Давайте не будем называть это «долгом». Давайте назовём это… техническим кредитом. И будем управлять им подобно тому, как финансисты используют свои финансовые инструменты.

Дмитрий Рыбаков

Дмитрий Рыбаков, технический директор школы программирования «Алгоритмика»

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

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

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

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

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

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

Сергей Грачев

Сергей Грачев, руководитель команды python-разработчиков Mediasoft

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

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

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

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

Андрей Мухин

Андрей Мухин, директор по разработке программного обеспечения Банки.ру

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

Мы работает по Scrum. Состав бэклогов команды и спринта контролируют руководитель проектов и тимлид команды, длительность спринта составляет две недели. Все задачи разработки делятся на три типа:

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

В каждом спринте для каждого из типов задач выделяется своя квота времени, которая учитывается при планировании:

  • Продуктовые задачи — 70% времени длительности спринта.
  • Поддержка — 20%.
  • Архитектурные — 10%.

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

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

Последнее и немаловажное мероприятие — актуализация бэклога задач технического долга.

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

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

  •  10% времени спринта тратится на задачи технического долга;
  • по завершении крупного проекта следует технический спринт;
  • в случае необходимости внедрения крупных технических изменений инициируется архитектурный проект;
  • бэклог технического долга всегда находится в актуальном состоянии, за этим следят и команды разработки, и линейные руководители разработки.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Подобрали три теста для вас:
— А здесь можно применить блокчейн?
Серверы для котиков: выберите лучшее решение для проекта и проверьте себя.
Сложный тест по C# — проверьте свои знания.

Также рекомендуем: