Практики agile: технические

7.1 Ежедневная сборка (build) и непрерывная интеграция

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

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

Два вклада в практику программирования, соответственно в инструментарий и методы, существенно улучшили ситуацию:

• начиная с инструментария, такого как достойные почитания: "Make", RCS (последовавшие далее CVS, Subversion, Git)^{1Make – первый инструментарий автоматической сборки программы из компонентов. Создан Стюартом Фельдманом в 1977 году. RCS – Revision Control System (1982 г.), CVS – Concurrent Version System (1986 г.) – системы управления конфигурациями программного проекта.}, стало возможным автоматизировать сборку компонентов и избежать при этом ужасных ошибок конфигурации (сегодняшняя версия модуля А комбинируется с устаревшей и несовместимой версией модуля В, созданной в прошлом месяце); поскольку интеграция включает и прогон тестов, инструментарий автоматического тестирования, обсуждаемый в этой главе, также оказывает существенную помощь;
• проекты перешли на более короткие циклы интеграции – не недели и месяцы, а дни и даже часы.

Наиболее заметным продвижением в этом направлении стала "ежедневная сборка", введенная в Майкрософт в восьмидесятые годы. Идея была проста. В конце каждого дня собираются все изменения, "введенные" (официально подписанные) разработчиками; система компилируется, прогоняются все тесты. Как отмечает менеджер Майкрософт [Cusumano 1995]:

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

Центральное правило "ежедневной сборки" иногда называют правилом "китайского магазина": в фарфоровых лавках Китая каждая сломанная или разбитая вещица считается купленной тем, кто это сделал. В программном магазине сломанную сборку чинит тот, по чьей вине произошел сбой. В традиционном для Майкрософт процессе виновнику вручается некоторый знак осуждения (платишь 5 долларов – получаешь козий рожок), помимо этого, приходится оставаться, пока проблема не будет устранена. Такие меры не очень сочетаются с agile принципами устойчивого темпа, но идея интеграции и непосредственной проверки остается.

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

Правила agile, в частности XP, идут дальше и вместо "ежедневной сборки" рекомендуют "непрерывную интеграцию". Правило Бека [Beck 2005]:

Интегрируйте и тестируйте изменения не реже, чем через несколько часов.

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

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

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

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

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

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

7.2 Парное программирование

Парное программирование – один из краеугольных камней экстремального программирования. В начальный период, когда agile был представлен главным образом XP, все дискуссии об agile неизбежно скатывались к обсуждению этой провокационной идеи. Проводились эмпирические исследования оценки эффективности этого подхода, его сравнения с традиционным подходом анализа кода. Сегодня парное программирование практикуется от случая к случаю (хотя энтузиасты все еще остаются и приходят с новыми вариантами, такими как мобпрограммирование), но оно перестало быть в круге света; другие практики agile считаются более важными.

Споры, главным образом, были следствием настаивания XP, что парное программирование является единственным и универсальным способом разработки программ. Бек писал:

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

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

7.2.1 Концепция парного программирования

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

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

Бек и другие авторы дают практические советы: "Установите компьютер так, чтобы партнеры могли сидеть удобно бок о бок", "прикрывайте рот при кашле", "избегайте сильных ароматических средств" и так далее.

Я знаю очень мало книг по инженерии программ, в которых обсуждаются проблемы личной гигиены. Еще одно извлечение из книги Бека, которая заслуживает некоторого рентгеновского просвечивания: "Когда программисты молоды и не могут отделять близость от возбуждения" (способствуют ли духи возбуждению?), "работа с персоной противоположного пола может привести к появлению сексуальных чувств", что "не в интересах команды" (к сожалению, в тексте ничего не говорится об интересах самих людей). Но ведь это же книга о проектах, так что учитываются интересы команды: "даже если чувства взаимны, эта увлеченность вредит команде". Чтобы убедиться, что читатели все понимают, в книге приводится фотография, где "мужчина слишком близок к женщине". Как положено, для сохранения интриги фото находится на следующей странице. Пожалуйста, не говорите моей жене, но я решился перевернуть страницу. Некоторые читатели вздохнут с облегчением, другие будут разочарованы; картинка напоминает семейную сцену. Участникам далеко за 18, полностью одеты, видны со спины, и их отделяют добрых два дюйма. Читайте вдохновляющую книгу Бека, но не для приятного возбуждения. Это страстный, захватывающий, пугающий роман, возможно, сценарий фильма (Голливуду стоит заинтересоваться). Я с нетерпением жду первого автора, кто, вдохновленный цитируемым текстом, напишет: "My Pair Lady", "The Pair Karamazov", "Fifty Shades of Pair".^{2Парафразы названий известных произведений: "Моя прекрасная леди", "Братья Карамазовы", "Пятьдесят оттенков серого" (Моя парная леди, Пара Карамазовых, Пятьдесят оттенков пары).}

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

Ответ корректен. После всего производительность, фигурирующая в индустрии, измеряется в числе строк кода, создаваемого программистом (метрика, всеми критикуемая и всеми используемая). Считается, что средняя производительность равна 20 строкам кода в день. Так как написание 20 строчек занимает несколько минут, то понятно, что большую часть времени программисты занимаются другой работой, в частности, размышляют о коде, который они напишут, корректируют очередной написанный код, исправляя ошибки. Если парное программирование действительно выдающийся процесс, то два программиста, работая вместе, могут создать более 40 строк кода в день. Если эти строки высокого качества, то проект получит преимущества. Так что тривиальные аргументы о снижении производительности не могут быть приняты без рационального анализа стоимости и преимуществ.

Эмпирические исследования не дают однозначного ответа [Miller 2005], [Navrocki 2001] в поддержку парного программирования. Когда оценивается этот подход по отношению к традиционным приемам обзора кода (когда предмет работы программиста подвергается коллективной инспекции) и PSP (Персональный Программный Проект), описанный в "Враг: предваряющий анализ" (3.6.2), то парное программирование показывает примерно те же результаты как по производительности, так и по качеству кода. Примерно, поскольку нет надежных результатов, но общий тренд ясен – прорыва нет.

7.2.2 Парное программирование, или работа с ментором

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

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

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

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

7.2.3 Мобпрограммирование

Если больше означает лучше, то зачем останавливаться на паре? Зуилл и некоторые другие энтузиасты XP провозгласили необходимость мобпрограммирования, определяя его так:

Все блестящие люди работают в одно и то же время в одном и том же помещении на одном и том же компьютере над одной и той же задачей.

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

Такие предложения показывают, что аджилисты становятся одним из наиболее плодовитых сообществ программной инженерии, лабораторией, вырабатывающей новые идеи. (Другие примеры еще слишком свежи, чтобы их можно было оценить в этой книге. Приведу лишь названия: трешинг – trashing, никаких оценок – no estimates, программистская анархия – programmer anarchy). Некоторые из них выживут, другие – нет. Слишком рано предсказывать судьбу каждой из них. Оценка, которая последует, ограничивается только парным программированием.

7.2.4 Парное программирование: оценка

Чтобы оценить парное программирование так же хорошо, как и другие agile приемы, полезно вспомнить бессмертные слова Бека, процитированные чуть выше: мы должны быть "достаточно взрослыми, чтобы отделить близость от возбуждения".

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

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

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

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

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

Одно дело – требовать, чтобы люди объясняли свою работу другим, другое, совершенно опасное – принуждать следовать единому стилю работы, особенно в случае креативной и сложной интеллектуальной деятельности. Когда Линус Торвальд создавал Linux, он работал в одиночку, но это не помешало ему показать свой код и позже привлечь тысячи людей к сотрудничеству. Много других примеров приходит на ум: Билл Джой и Berkeley Unix, Ричард Столлмен и Emaks, Дональд Кнут и TeX. (На секунду подумайте, блестящей ли является идея заставить Дона Кнута работать в паре. Пусть кто-нибудь попытается.)

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

Настаивание на том, что парное программирование является единственно правильным способом, встречало возражения и со стороны некоторых защитников agile. Ларман [Larman 2010], например, указывает:

Парное программирование – это только практика XP, она не требуется в Scrum.

Хотя первая часть этого комментария является преувеличением, поскольку сторонников парного программирования достаточно много, помимо XP, отказ Scrum принять догматическое применение парного программирования вполне объясним.

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

7.3 Стандарты кодирования

Методы Agile предполагают, что команды должны следовать строгим стандартам кодирования, способствующим повышению качества кода. В оригинальном описании экстремального программирования Бек [Beck 2000] пишет:

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

Стандарты кодирования трудно назвать новой идеей. Каждая уважающая себя организация устанавливает точные правила стиля программирования. Что следует особо отметить в приведенной выше цитате, помимо необходимости иметь стандарты кодирования, так это замечание, что никто не может определить авторство кода, предполагающее "безликое программирование". Это тоже старая идея, появившаяся в девяностые годы и критиковавшаяся как некоторый стиль программирования в духе Джилберт-босса, подавляющего креативность и индивидуальность программирования. Странно, что эта идея возрождается в рамках совсем другой идеологии. Этому нельзя не удивляться. Все эти акценты agile на коммуникации и сотрудничество великолепны, но, в конечном счете, великие программы написаны великими программистами (такими как Кент Бек). Linux несет марку Торвальда, Berkeley Unix – Джоя, TeX – Кнута, xUnit – Бека и Гаммы, никого из них представлять не требуется. Даже в проектах с участием простых смертных наиболее сложные части проекта выполняются лучшими программистами.

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