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

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

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

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

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

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

Рассмотрим подробнее, что такое простота и что такое наборы тестов.

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

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

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

• Обратная связь – одна из проблем, с которой мне приходилось сталкиваться в процессе проектирования, прежде чем я начал практиковать ХР, состояла в том, что я никогда не мог сказать точно, прав я или нет. Чем дольше я проектировал, тем значительней становилась эта проблема. Простой дизайн решает проблему благодаря тому, что он формируется быстро. Далее следует закодировать его и посмотреть, как выглядит и ведет себя код.

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

Следуя этим ценностям, мы должны:

• сформировать стратегию проектирования, в результате использования которой формируется простой дизайн;

• найти быстрый способ убедиться в том, что дизайн качественный;

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

• сжать цикл времени, в течение которого выполняется весь этот процесс, и сделать его как можно короче.

Принятые нами ранее принципы также хорошо воплощаются в стратегии дизайна.

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

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

• Постепенное изменение – стратегия дизайна будет работать благодаря постепенному изменению. Мы будем проектировать постепенно и понемногу. Никогда не наступит момент времени, когда можно будет сказать, что система полностью спроектирована. Дизайн системы будет постоянно меняться, однако при этом некоторые части системы, возможно, будут оставаться неизменными в течение некоторого времени.

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

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

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

Рис. 8. Если стоимость затрат стремительно растет с течением времени

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

Проблема, связанная с этой стратегией, – это неопределенность.

На практике: