Глава 16. Стратегия разработки

Глава 16.

Стратегия разработки

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

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

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

Постоянная интеграция

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

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

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

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

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

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

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

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

Коллективное владение

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

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

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

Коллективное владение усиливает ощущение вашей личной власти над проектом. В рамках ХР-проекта вы никогда не проклинаете в бессилии чужую тупость, мало того, чужая тупость никогда не становится непреодолимой преградой на вашем пути. Если вы видите на своем пути препятствие, вы просто избавляетесь от него. Если вы предпочитаете сохранить что-либо, потому что это вам подходит, – это ваше личное дело. Но при этом вы никогда не попадаете в тупик. У вас никогда не возникает ощущения, что: Я мог бы отлично справится с моей работой, если бы только не все эти идиоты вокруг меня. А это значит, что у вас исчезает еще одна причина для огорчения. Вы еще на один шаг ближе к чистому мышлению.

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

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

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

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

Также следует отметить, что программирование в паре – это не сеанс обучения. Иногда в состав пары входят два партнера, один из которых обладает существенно большим опытом, чем другой. Когда такое происходит, первые несколько сеансов парного программирования во многом напоминают уроки. Менее опытный партнер задает множество вопросов и вводит в компьютер относительно немного кода. Однако через короткое время менее опытный партнер начинает отлавливать грубые ошибки, такие как несоответствие открывающихся и закрывающихся скобок. Более опытный партнер заметит, что оказываемая им помощь востребована. Еще через несколько недель менее опытный партнер приступит к использованию более крупных образцов кода, чем использует его более опытный соратник. Для него станет понятным разница между образцами кода.

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

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

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

Что если кто-то отказывается работать в парах? Такие люди либо должны научиться работать так, как работает вся остальная команда, либо должны работать вне команды. ХР подходит далеко не каждому, и далеко не каждый подходит для ХР. Однако вовсе необязательно с самого первого дня внедрения ХР все свое рабочее время программировать в паре и только в паре. Как и ко всему остальному в ХР, вы должны привыкать к программированию в парах постепенно. Попробуйте работать в паре в течение часа. Если у вас плохо получится, попытайтесь понять, что именно вы делаете не так, затем попробуйте поработать в паре еще один час.

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

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

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

Еще одной важной особенностью программирования парами является то обстоятельство, что некоторые из методик ХР без него не работают. В состоянии стресса люди забывают о правилах хорошего тона. Они перестают писать тесты. Они отказываются от выполнения переработки. Они откладывают на потом интеграцию. Однако если за вами следит ваш партнер и при этом вы собираетесь нарушить одну из методик, у вас возникает чувство вины. Вам неудобно перед вашим партнером, так как вам кажется, что он никогда бы так не поступил. Сказанное не означает, что пары никогда не нарушают нормальный ход процесса разработки. Конечно же иногда это происходит, в противном случае вам не понадобился бы инструктор (coach). Однако если вы работаете в паре, вероятность того, что вы проигнорируете некоторые общепринятые правила, ниже, чем если бы вы работали в одиночку.

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

Данный текст является ознакомительным фрагментом.