Это третья часть моей серии о современных практиках разработки программного обеспечения. В этой серии я расскажу о нескольких способах, которыми инженеры-программисты могут улучшить свое программное обеспечение, улучшив свои процессы и методы, и все из которых я изучил и прожил, работая консультантом по программному обеспечению в ThoughtWorks, и испытал на себе текущую работу в крупной розничной торговле. компания в Германии.
Как человек, которому нравится отстаивать вещи, которые, по моему мнению, очень полезны для эффективности команды разработчиков программного обеспечения, я потратил много времени на то, чтобы отреагировать на некоторые из практик, в которые я верю.
Одна из моих самых любимых тем - это магистральная разработка (TBD). По совпадению, эта тема также вызывает наибольшую негативную реакцию со стороны других разработчиков программного обеспечения.
Мне нравится эта тема, потому что я не люблю стереотипы, а разработка на основе магистралей напрямую борется со множеством стереотипов, жертвами которых становятся разработчики программного обеспечения.
Когда люди, не работающие в нашей отрасли, слышат фразу «разработчик программного обеспечения», они думают о мифах инженера-программиста. Почти как мифическое существо, это тот, кто надевает наушники, работает с 3 или 4 мониторами и зелеными персонажами на черных экранах. Кто-то, кто получает задание, а затем уходит в свою пещерную рабочую среду, пока не завершит свою задачу через короткое время.
Прекрасный тому пример - создатель игры 2048. Ходят слухи, что 19-летний парень создал игру за один уик-энд, а через 2,5 недели после выпуска игры в нее было сыграно 100 миллионов раз
Это прекрасно воплощенный стереотип разработчика программного обеспечения. Иногда это круто, но я считаю, что это отрицательно сказывается на разработке программного обеспечения в команде.
Разработка на основе магистральных линий - это форма разработки, которая в буквальном смысле невозможна, пока в команде существует стереотипный разработчик.
Магистральная разработка требует командной работы, сочувствия и открытости. Все это лучше всего достигается в команде, а не в индивидуальном порядке.
Что такое магистральная разработка?
Trunk Based Development, также известная как TBD, - это процесс разработки программного обеспечения, который определяется trunkbaseddevelopment.com (отличный источник всего, что подлежит уточнению) как:
«Модель ветвления управления исходным кодом, при которой разработчики совместно работают над кодом в одной ветке, называемой« магистралью »*, противостоит любому давлению с целью создания других долгоживущих ветвей разработки, используя документированные методы. Поэтому они избегают адского слияния, не ломают конструкцию и живут долго и счастливо ».
Идея состоит в том, что вместо создания функциональной ветки, на которой разработчик разрабатывает код, а затем сливается с основной ветвью, функция разрабатывается небольшими порциями, каждый из которых по завершении напрямую передается в мастер.
Другими словами… команда развивается без использования веток.
Теперь ... я знаю, что большинство разработчиков, которые были в отрасли какое-то время, мгновенно отключаются от идеи TBD, когда видят, что «насаждают на мастера» ... но выслушайте меня, и я постараюсь решить те проблемы, которые я слышу больше всего в этой статье.
Почему это важно?
Я снова возвращаюсь к четырем ключевым показателям, определенным в Accelerate, и их важности. Прямая цитата из книги:
«В нашем исследовании выделяются практики, которые необходимы для успешных технологических преобразований. К ним относятся использование контроля версий, автоматизация развертывания, непрерывная интеграция, разработка на основе магистрали и слабосвязанная архитектура ».
Практики, которые не просто важны ... но необходимы. Это значит абсолютно необходимо. Я писал о непрерывной интеграции несколько постов назад, и разработка на основе магистралей также находится в этом списке.
Помимо того факта, что небольшие изменения кода в формате разработки на основе магистралей приводят к гораздо меньшему количеству конфликтов слияния (что означает более счастливые разработчики), разработка на основе магистралей помогает командам улучшаться в ряде областей:
Частота развертывания и среднее время восстановления
TBD в сочетании с конвейером CI / CD приводит к тому, что каждая «зеленая» фиксация (т.е. полная функциональность кода проверена с помощью тестов) развертывается в производственной среде. Отправка каждого изменения в основную ветвь означает большую интеграцию и, возможно, развертывание. Я был в командах, где мы развертывали 30–40 раз за один день в продакшн. Повышенная частота развертывания - второй из четырех ключевых показателей.
Я могу вспомнить ситуацию в той же самой команде, где мы развернули что-то в интерфейсном приложении, которое было чем-то вроде «отображать список элементов с соответствующими атрибутами», и мы забыли проверить нулевые или неопределенные значения. . Это вызвало ошибку во внешнем интерфейсе.
Конечно, это может случиться с любой командой, независимо от того, какие процессы они используют ... но что было удивительно, мы заметили это сразу и смогли написать тест и исправить проблему, которая была зафиксирована и развернута в продакшене в менее 5 минут. Низкое среднее время восстановления - третий из четырех ключевых показателей.
Эта способность быстро развертывать изменения с помощью магистральной разработки и CI / CD также позволяет группе «откатывать вперед» при обнаружении проблем, а не «откатывать назад».
Качество кода и обмен знаниями
Наибольшее опасение, которое команды обычно испытывают при рассмотрении вопросов, подлежащих уточнению, заключается в том, что качество кода в базе кода пострадает при разработке на основе магистралей, и вероятность ошибок возрастет. Я, однако, придерживаюсь совершенно противоположного мнения и считаю, что TBD приводит к гораздо более устойчивому и более качественному коду.
Большинство команд, использующих функциональные ветки, используют метод запроса на вытягивание, при котором другие разработчики в команде будут просматривать и комментировать код, над которым разработчик работал более X времени.
С TBD, поскольку нет функциональных веток, это также означает отсутствие запросов на вытягивание. Вставьте сюда обеспокоенного старшего разработчика. Это не должно быть проблемой. Большинству команд просто нужен «принцип четырех глаз», который гласит, что как минимум два разработчика должны были просмотреть и утвердить весь код, который объединен в основную ветку.
Моя команда также занимается «Принципом четырех глаз», но мы делаем это с помощью парного программирования (статья скоро появится). Поскольку в TBD нет запросов на вытягивание, парное программирование становится крайне необходимым.
Два разработчика, работающие вместе для решения одной и той же проблемы, довольно часто лучше, чем один разработчик, работающий в одиночку. Все разработчики имеют разный уровень опыта и знакомы со стеком технологий и / или системой, которую разрабатывает команда. Объединение друг с другом дает возможность учиться у товарищей по команде в ускоренном темпе.
Представьте, как быстро повышается уровень младшего инженера или нового сотрудника в паре со старшим инженером в команде. Руководства по командному кодированию мгновенно изучаются и выполняются, проектные решения принимаются до того, как работа будет выполнена, а не в виде обратной связи в запросе на вытягивание, и код пишется вместе, в результате чего оба разработчика знают, как это работает (т. Е. Меньше разрозненных знаний).
Работа в команде
Парное программирование, очевидно, также является формой командной работы, но TBD улучшает командную работу в команде, поскольку требует сочувствия от всех участников.
Старшему разработчику, проработавшему много лет над системой, может быть сложно чувствовать себя комфортно с новыми или менее опытными членами команды, приверженными кодовой базе, а старший это не видит. Но сочувствие, необходимое для того, чтобы смириться с этим, - это, как правило, очень положительное качество для товарища по команде. Вера в то, что товарищи по команде способны выполнять свою работу и им не нужно быть главным смотрителем филиала, очень важна для уверенности и доверия внутри команды.
Старшие инженеры умны и в большинстве случаев имеют хороший опыт, но люди в их командах тоже умны. Если старший хочет видеть код, написанный младшим, они могут объединиться в пары, и раньше, чем они это узнают, младший будет писать код, которым старший будет гордиться.
Возможные проблемы:
Незавершенные функции
Никто не хочет предлагать клиентам в производственной среде незавершенные функции, такие как кнопка без функций. Чтобы обойти это, команды могут реализовать переключатели функций, за которыми скрываются незавершенные функции. Когда функция не завершена, переключатель функции отключается, а когда последняя часть сделана и готова к выпуску, флаг функции можно включить (или полностью удалить). С переключателями функций команды могут даже проводить A / B-тестирование или Canary Releases.
Тесты и мониторинг
Для разработки на основе магистрали требуется, чтобы у команды был надежный набор тестов и хороший мониторинг, чтобы выявлять ошибки как можно скорее. Чем быстрее обратная связь, тем лучше. Неисправный конвейер становится приоритетом номер один для членов команды, нарушивших конвейер, чтобы никто не мог извлечь сломанный код.
Этого можно легко предотвратить, внося очень небольшие изменения, имея среду разработки, которая максимально похожа на ваши тестовые и производственные среды, и выполняя задачи конвейера локально перед нажатием (например, с помощью git hooks).
Я знаю много команд, которые реализовали разработку на основе магистрали, как описано в этой статье, и ни одна из них не вернулась к более распространенной модели запроса на включение.
Некоторые команды даже переключаются на разработку на основе магистрали по другим причинам, например, они хотят больше заниматься парным программированием, поэтому они перешли на разработку, которая подлежит уточнению, чтобы сделать парное программирование более требовательным.
Я думаю, что важно помнить, что, как и все в программном обеспечении и в жизни, одно и то же работает не для всех. Важно, чтобы команды смотрели на то, что им больше всего подходит. Примером может служить моя знакомая команда, в которой было нечетное количество разработчиков, что означало, что у них не было возможности объединяться для всех задач, и иногда они так часто выгорали из-за объединения. В этой ситуации у них были функциональные ветви, которые были созданы и объединены в тот же день, что, как ни удивительно, считается TBD.
Следующие шаги: попробуйте Trunk Based Development, адаптируйте ее к потребностям команды, получите прибыль.
