В современном мире разработки программного обеспечения существует миф о противостоянии между техническим совершенством решений и бизнес-целями компании. Однако, по мнению эксперта в области инженерных практик Антона Бевзюка, это ложная дихотомия. Качественный код, созданный с соблюдением инженерных принципов, приводит к ускорению разработки и улучшению конечного продукта.
Качество как способ достижения бизнес-ценности
Часто приходится слышать вопрос: «Что важнее – качество или скорость?». В реальности эти два фактора взаимосвязаны. Экстремальное программирование (XP) пропагандирует принципы, согласно которым простота и отказ от избыточной сложности позволяют быстрее получать обратную связь, оперативно вносить изменения и поддерживать высокое качество продукта. Инженерные практики помогают создать систему, которая легко адаптируется к изменениям, минимизируя технический долг и повышая скорость доставки нового функционала.
Что инженерные практики дают бизнесу?
Инженерные практики обеспечивают:
- Гибкость и адаптивность – быстрый отклик на изменения рынка и потребностей пользователей.
- Минимизацию затрат на поддержку – качественный код проще тестировать, изменять и расширять.
- Снижение числа багов – автоматизированные тесты, рефакторинг и парное программирование уменьшают вероятность критических ошибок.
- Устойчивость к изменениям состава команды – благодаря принципам коллективного владения кодом и автоматизированного тестирования.
Zero Bug Policy: Как справиться с багами?
Одна из ключевых инженерных практик – Zero Bug Policy, подход, при котором накопленные ошибки в бэклоге не хранятся годами, а либо устраняются немедленно, либо закрываются как неактуальные. Самое сложное в этом процессе – убедить команду отказаться от накопленного списка багов, но статистика показывает: если ошибка остается нерешенной более трёх месяцев, скорее всего, она так и останется нерешенной. Подход Zero Bug Policy позволяет сосредоточиться на текущих проблемах и поддерживать высокое качество продукта.
Как внедрять инженерные практики?
Инженерные практики должны решать реальные проблемы команды. Ошибка многих технических лидеров – внедрение новых методик без четкого понимания их ценности для бизнеса и команды.
Лучший способ – дать возможность разработчикам попробовать новую практику в безопасном эксперименте, а затем самостоятельно принять решение о её дальнейшем использовании.
Парное программирование и его преимущества
Парное программирование часто вызывает сопротивление как у инженеров, так и у менеджеров. Однако исследования показывают, что:
- Несмотря на снижение объема написанного кода (примерно на 30%), его качество значительно выше.
- В коде меньше багов, а архитектурные решения принимаются осознаннее.
- Новые сотрудники быстрее встраиваются в команду.
Менеджмент часто опасается, что парное программирование снижает производительность, но в долгосрочной перспективе оно снижает затраты на исправление багов и технический долг, что приносит бизнесу реальную выгоду.
На какие процессные метрики влияют различные инженерные практики? Мы уже немного говорили про пропускную способность, а что насчет времени производства?
Возьмем, например, парное программирование в комбинации с Test-Driven Development (TDD). Это означает, что ты большую задачу разбиваешь на серию очень небольших шагов, каждый из которых завершается за 10-15 минут. Причем сразу же получаешь код-ревью, то есть твой код достигает production-ready качества. Конечно, задача еще не выполнена за 10 минут, но первый шаг сделан, первая строчка работающего кода написана. Причем не просто кода, а кода, покрытого тестами. И эта часть уже может быть интегрирована, разработчики могут давать фидбек, рефакторить. Таким образом, lead time для этого фрагмента кода сокращается до минимума.
Представь, что ты идешь к цели по ступенькам. Они маленькие, но каждая приближает тебя к конечному результату. Такой подход повышает вероятность успеха, в отличие от стратегии «одной большой ставки», когда ты надеешься попасть в цель с первого раза, но в случае ошибки придется все переделывать. Это увеличивает lead time в разы.
Также стоит учитывать, что одна и та же функциональность, реализуемая на разных этапах жизни продукта, может иметь разный lead time из-за накопления технического долга. Если ты применяешь парное программирование и Test-Driven Development, ты выравниваешь этот показатель. Постоянный рефакторинг и упрощение кода позволяют поддерживать его в состоянии, в котором его всегда легко понять и изменить. Это делает lead time предсказуемым, что само по себе уже является большим преимуществом.
Кроме того, работая в паре, ты сокращаешь WIP-лимит, что также способствует уменьшению lead time. Автоматизация тоже играет роль: вместо двух недель регресса тесты прогоняются за три дня. А если добавить современные практики, такие как continuous delivery, lead time сокращается до минимума – код пушится, тут же попадает в pipeline, проходит тесты и уходит в продакшн.
Сoding mother..cker
Есть такой подход – «coding mother..cker», его сторонники говорят: «Не важно, что мы делаем, главное – кодить». Является ли это разумным подходом? Возможно, в каких-то контекстах, например, на хакатоне. Если цель – быстро накидать работающий прототип, почему бы и нет? Но в долгосрочной перспективе такой метод неустойчив. Даже в условиях хакатона полезно работать в паре или в мобе – больше идей, выше качество.
Универсальные специалисты
Стоит ли стремиться к универсальности разработчиков? Абсолютно универсальных людей не бывает, но расширять диапазон компетенций – выгодно как компании, так и самим специалистам. Новые знания обогащают существующие навыки. Например, если джавист познакомится с фронтендом, он может привнести в свой бэкенд-код принципы функционального программирования. Это повысит надежность кода, уменьшит число багов и упростит тестирование.
Make it work, make it pretty, make it fast
Один из способов декомпозиции – сначала сделать, чтобы работало, потом – чтобы было красиво, а затем – чтобы было быстро. Это не единственный возможный подход, но в разумных пределах – вполне рабочий. Он позволяет быстрее получить фидбек, выявить узкие места, затем оптимизировать и только потом заниматься эстетикой. Однако порядок можно менять в зависимости от ситуации.
Как стать скрам-мастером, которого не ненавидят разработчики?
Если скрам-мастер приносит пользу – его не ненавидят. Главное – не просто цитировать Scrum Guide, а понимать, какие проблемы есть у команды и как их решать. Хороший скрам-мастер помогает, а не заставляет следовать догмам. Он должен слушать команду, учитывать, что уже пробовали, и предлагать идеи, которые действительно могут помочь.
Пропаганда инженерных практик без их знания
Можно ли продвигать инженерные практики, не зная их на практике? Теоретически да, но сложно. Однако базовое понимание терминов и принципов уже дает возможность разговаривать с разработчиками на их языке. Например, один из эффективных подходов – обучение инженеров и менеджеров основам инженерных практик через простые аналогии (например, объяснение работы Git через написание книги).
Инженерная практика, без которой нельзя обойтись в современной разработке
Рефакторинг. Без него код быстро превращается в хаос, усложняющий внесение изменений и увеличивающий вероятность багов.
30% времени на технический долг
Техническим долгом нужно управлять так же, как бизнес-требованиями. Если проблема критична и без ее решения система не выдержит рост нагрузки, ее нужно решать. Фиксированное выделение 30% времени на технологический долг – это попытка искусственно упростить процесс. Гораздо важнее уметь обосновывать необходимость таких работ бизнесу.
Один из подходов – выделение отдельной команды, сфокусированной на поддержке продукта. Они занимаются исправлением багов, мелкими бизнес-доработками и устранением технологического долга, управляя этим процессом через Канбан-лейны.
100% покрытие тестами при TDD – миф или реальность?
Реальность. Но не в том смысле, что 100% строк кода покрыты тестами, а в том, что вся логика, где есть условия, циклы и исключения, оказывается под тестами. Это достигается не количественным подходом, а строгим процессом написания тестов перед кодом.
