Каждому разработчику знакома ситуация, когда внедрение новой функции в систему занимает много времени, а релиз уже близок, а тимлид или руководитель проекта пятый раз за день задает и без того надоевший вопрос: « Когда это будет готово?" И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения функционал.
Очевидно, что в большинстве случаев будет выбран второй вариант, поскольку выпуск и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы.
Но проходит несколько месяцев, и теперь старое, не идеальное техническое решение мешает реализации другого функционала.
И тогда такие решения будут скапливаться в огромный ком.
Решая эту проблему, очень важно сделать правильные выводы и выбрать правильное решение.
От этого решения будет зависеть дальнейшая судьба всего проекта.
В этой статье мы попытаемся понять природу технического долга и посоветовать пути его устранения.
Природа технического долга
Впервые понятие технического долга было предложено Уордом Каннингемом.Уорд Каннингем ), разработчик технологий вики и один из создателей экстремальное программирование .
В 1992 году в своем статья эту концепцию он сформулировал в виде метафоры финансового долга: так же, как и в случае с финансовым кредитом, разработчики могут получить дополнительные средства здесь и сейчас за счет использования быстрых и неоптимальных технических решений, но неизбежно будут платить за них в ходе дальнейшей разработки независимо от того, того, как будет погашен этот долг – поэтапной выплатой процентов или одним платежом.
Но если проблема технического долга была описана 25 лет назад и встречается практически в любом проекте, то почему не существует методологии управления проектами, которая позволяла бы избежать самого появления технического долга? Ответ кроется в самой концепции проекта.
Одним из ключевых отличий проекта от других видов деятельности является уникальность конечного продукта.
Где уникальность, там и непредсказуемость, и именно она порождает изменения в проекте и вносит трудности в первоначальное проектирование системы.
Конечно, можно попытаться построить архитектуру, допускающую возможные изменения, но здесь команда столкнется с такой концепцией, как « кошелек Миллера »: правило, по которому в кратковременную память человека можно «положить» одновременно не более девяти «монет».
А если количество элементов превышает это значение, то мозг пытается сгруппировать информацию так, чтобы их количество было от пяти до девяти.
Можно попробовать разделить компоненты на более мелкие, чтобы уместиться в этот «кошелек», но сложность от этого меньше не станет, а количество абстракций при таком подходе будет расти с катастрофической скоростью.
А как известно, любую проблему можно решить введением дополнительного уровня абстракции, за исключением проблемы слишком большого количества уровней абстракции.
Другие команды предпочитают вообще отказываться от первоначального проектирования, стараясь максимально использовать универсальные инструменты при разработке.
С одной стороны, это проще, чем пытаться прогнозировать изменения, и на первых этапах система будет достаточно гибко поддаваться изменениям.
Но со временем сложность системы, по мнению Второе правило Лемана , неизбежно будет расти, станет менее гибким, и могут произойти изменения, идущие вразрез с текущей архитектурой.
В этом случае разработчики также будут тратить больше времени на решение архитектурных задач.
Так или иначе, неизбежность изменений в проекте провоцирует появление технического долга.
Как определить, есть ли у проекта проблема технического долга
Самым важным индикатором того, что у проекта есть проблема технического долга, является, конечно же, сам код. Прежде всего, стоит упомянуть об особенностях написания кода.Дело в том, что написание и чтение кода — это два совершенно разных процесса.
Когда разработчик пишет код, он сосредоточен только на контексте задачи.
Но изменение отдельного участка кода влияет на общую картину происходящего.
В свою очередь, прежде чем менять написанный код, нужно иметь представление не только о конкретной области, но и обо всей картине в целом.
Но по мере чтения границы контекстов, в которых был написан код, в общем виде размываются.
Эта разница между чтением и написанием кода порождает дополнительную сложность, которая напрямую влияет на его качество.
На что нужно обратить внимание:
- Разделы кода, которые часто изменяются.
Скорее всего, эти направления требуют серьезного улучшения.
- Большое количество пометок FIXME и TODO и малое количество комментариев в коде должны вас насторожить.
Современные IDE имеют встроенную поддержку работы с такими тегами, поэтому это один из самых быстрых и надежных способов выявления слабых мест в системе.
- Отсутствие тестов.
Без них у разработчиков нет уверенности, что их изменения не сломают систему.
Команда относится к коду, не охваченному тестами, как к карточному домику, стараясь избегать ненужных, а иногда и необходимых изменений.
- Отсутствие документации.
Ситуация аналогична предыдущему пункту.
Отсутствие регламентированной информации вынуждает разработчика самостоятельно составлять картину происходящего, и есть вероятность, что у него возникнет неправильное представление о системе.
Ситуация усугубляется тем, что в подавляющем большинстве случаев над проектом работают разработчики разного уровня подготовки и компетентности.
А различия в понимании кода еще больше усложняют процессы чтения и написания кода.
- Устаревшие технологии и инструменты разработки.
Любая библиотека или модуль обновляется, и поддерживать старые версии со временем становится все сложнее и дороже.
- Отсутствие стандартов разработки.
Каждый разработчик делает то, что и как хочет.
Методики ликвидации технического долга
- Как и при лечении любого заболевания, самым первым шагом к выздоровлению является признание того, что вы больны.
Ведь в первую очередь каждый участник проекта, от заказчика до разработчика, должен осознать проблему растущего технического долга.
Не так давно я стал тимлидом на одном большом проекте, который нам достался по наследству, и работы по техническому долгу на нем так и не велись.
Перебирая огромное количество задач, я постоянно натыкался на задачи по устранению технического долга, которые создавались разными людьми в разное время, но так и не были реализованы.
Это говорит о том, что попытки справиться с техническим долгом в одиночку сравнимы с борьбой с ветряными мельницами.
Очень важно, чтобы участники проекта знали об этой проблеме, поскольку ее решение требует исключительно системный подход.
- Используйте гибкие методологии разработки ( Гибкий ).
Основная суть методик — разбить разработку на небольшие изолированные итерации продолжительностью от одной до четырех недель.
Таким образом обходит ограничение «кошелька Миллера», ведь теперь на каждой итерации нужно работать только с ограниченным потоком информации, в котором легче управлять сложностью, и, соответственно, техническим долгом.
- Ввести общий и понятный регламент работы с техническим долгом.
Создайте бэклог, содержащий задачи для его погашения.
И добавляя новый функционал или планируя следующую итерацию, найдите время для выполнения этих задач.
Вы можете попробовать выделить время только на выполнение этих задач, но тогда разработка нового функционала заморозится, и скорее всего вы столкнетесь с непониманием со стороны бизнеса.
В нашем проекте мы решили 20%-30% времени от следующей итерации выделить на погашение технического долга.
- Создавайте показатели, которые помогут вам отслеживать прогресс технического долга.
Такие метрики индивидуальны для каждого проекта.
Например, для нашего проекта мы определили такие метрики, как процент покрытия тестированием и документацией, соответствие кода принятым руководствам по стилю, а также сложность развертывания системы в локальной среде разработчика.
Некоторые показатели собираются автоматически, некоторые — только субъективно каждым разработчиком.
Важно, чтобы эти метрики были доступны всем, чтобы каждый участник видел прогресс и был с ним согласен.
Заключение
Проблема технического долга на данный момент очень актуальна, и каждый проект требует индивидуального подхода к проблеме его устранения.Не бойтесь выплат, ведь если вы примете правильную стратегию, технический долг станет той силой, которая заставит ваш проект развиваться.
Именно работа с техническим долгом показывает уровень зрелости как самого проекта, так и команды, которая над ним работает. Теги: #Управление разработкой #Управление проектами #разработка #управление проектами #технический долг #рефакторинг
-
Маховик
19 Oct, 24 -
Новогодний Креатив
19 Oct, 24 -
Jetbrains На Rubyconfby В Минске 22 Марта
19 Oct, 24 -
Дерево, Отображаемое Хеш-Массивом
19 Oct, 24
