Уничтожьте технический долг до того, как он убьет ваш проект

Негативное влияние технического долга на бизнес огромно.

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

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

Давайте определим технический долг...

Часто [технический долг] (https://www.stepsize.com/blog/complete-guide-to-technical-debt) относится к ускоренному процессу разработки или отсутствию общих знаний между членами команды. Однако не забывайте, что во многих случаях технический долг неизбежен и является частью нормального процесса разработки программного обеспечения.

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

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

1. Технический долг, основанный на знаниях

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

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

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

2. Задолженность по дизайну

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

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

Таким образом, проектный долг тесно связан со структурированием функций и соблюдением шаблонов проектирования.

3. Код долга

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

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

3 лучших способа борьбы и предотвращения технического долга

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

1. Рефакторинг кода и архитектуры

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

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

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

Недостаток: Процесс разработки замедляется, пока вы проводите рефакторинг, а ваша команда не занимается решением долгов постоянно.

2. Начать регулярное обсуждение технического долга

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

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

Преимущество: вы можете использовать ретроспективные собрания, чтобы делиться новостями о коде. Инженеры могут показать, чего они достигли. В основном пара инженеров получает возможность представить свои изменения в кодовой базе и объяснить, как они влияют на кодовую базу или как они этого добились. Таким образом, ретроспективная встреча — отличный инструмент для обмена знаниями после каждого спринта.

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

3. Начните отслеживать технический долг в своем редакторе

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

• Получите полную информацию о техническом долге

• См. контекст для каждой проблемы с кодовой базой

• Уменьшить переключение контекста

• Постоянно решать технический долг

Вы можете использовать различные инструменты для отслеживания технического долга, но самый быстрый и простой способ начать — это используйте бесплатные расширения Stepsize для VSCode или JetBrains, которые интегрируются с Jira, Linear, Asana и другими инструментами управления проектами.

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

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

Как обнаружить растущий технический долг?

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

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

• Общий процент покрытия кода и покрытие кода для каждой функции: снижение процента является сигналом растущего технического долга.

• Количество неудачных сборок CI или CD. Если количество неудачных сборок CI/CD увеличивается, это явный признак нестабильности вашей кодовой базы. Это может быть связано как с дизайном, так и с задолженностью по коду.

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

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

• Проблемы с нефункциональными требованиями. Думали ли вы об измерении нефункциональных требований при определении показателей для выявления технического долга? Измерение таких показателей, как производительность приложения, UX (все более сложный в использовании) или потеря совместимости, являются надежными индикаторами увеличения технического долга. Если вы хотите начать работу с этой метрикой, попробуйте мониторинг производительности для критических путей в вашем приложении.

Как компании на разных этапах по-разному справляются с техническим долгом?

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

Однако крупным предприятиям не так просто держать технический долг под контролем. Согласно [Отчету о состоянии технического долга за 2021 г.] (https://stepsize.com/report), 66 % инженеров считают, что команда будет работать на 100 % быстрее, если у них будет процесс управления техническим долгом. Еще 15% считают, что они будут даже на 200% более продуктивными.

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

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

Кроме того, они должны использовать автоматизированные инструменты качества кода для обеспечения общего состояния кодовой базы. Инструменты качества кода часто можно интегрировать в конвейер [непрерывной интеграции] (https://www.atlassian.com/continuous-delivery/continuous-integration).

Заключение

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

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

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

Также опубликовано Майклом Мердерсом в блоге Stepsize