Глава 11. Как это работает?

Глава 11.

Как это работает?

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

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

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

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

Игра в планирование

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

Однако в ХР:

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

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

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

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

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

Небольшие версии

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

Однако в ХР:

• игра в планирование помогает вам работать над наиболее важными историями, поэтому даже небольшая система в состоянии приносить пользу бизнесу;

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

• в процессе разработки вы постоянно выполняете тестирование системы, благодаря этому количество дефектов в системе настолько мало, что вам не требуется заниматься длительным и болезненным предпродажным тестированием продукта перед тем, как вводить его в эксплуатацию;

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

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

Метафора

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

Однако в ХР:

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

• вашему заказчику очень удобно разговаривать о системе в терминах метафоры;

• вы выполняете переработку (refactor) для того, чтобы постоянно пересматривать ваше представление о том, что метафора означает на практике.

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

Простой дизайн

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

Однако в ХР:

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

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

• вы программируете не один, а с партнером, поэтому вы можете быть уверенными в том, что вы формируете простой дизайн, а не глупый дизайн.

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

• у вас есть тесты, поэтому вряд ли вы нарушите целостность кода, не узнав об этом сразу же;

• вы постоянно выполняете интеграцию системы, поэтому если вы нечаянно нарушите что-либо в системе или выполненная вами переработка конфликтует с чьей-либо работой, вы узнаете об этом в течение ближайших нескольких часов;

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

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

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

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

Однако в ХР:

• стандарты кодирования снижают трения между членами пары;

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

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

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

• пары работают в рамках простого дизайна, поэтому оба программиста в паре без затруднений понимают, что, собственно, происходит.

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

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

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

Однако в ХР:

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

• вы пишете и постоянно запускаете тесты, поэтому вероятность нарушения работы системы снижается;

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

• вы действуете в рамках стандартов кодирования, поэтому конфликты стиля не возникают, а код становится понятным каждому члену команды (например, ситуация, когда разные люди привыкли ставить фигурные скобки по-разному, называется Curly Brace Wars – война фигурных скобок).

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

Постоянно продолжающаяся интеграция

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

Однако в ХР:

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

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

• вы выполняете переработку кода, и в процессе этого устраняется значительная часть конфликтов.

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

40-часовая рабочая неделя

Вы не можете работать только 40 часов в неделю. Вы не успеете выполнить весь необходимый объем работ.

Однако в ХР:

• игра в планирование заставляет вас делать наиболее важную работу в первую очередь;

• комбинация игры в планирование и тестирования снижает вероятность возникновения неприятных сюрпризов (именно такие сюрпризы являются причиной того, что приходится работать сверхурочно);

• весь набор рассматриваемых методик помогает вам программировать с максимальной скоростью, поэтому вы все равно не сможете сделать запланированный на неделю объем работ быстрее.

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

Заказчик на месте разработки

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

Однако в ХР:

• представитель заказчика приносит пользу для проекта, так как он пишет функциональные тесты (предприятию-заказчику все равно придется этим заниматься);

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

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

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

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

Однако в ХР:

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

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

Заключение

Любая из рассмотренных методик сама по себе плохо приспособлена для использования в рамках программистского проекта (за исключением, возможно, тестирования). Чтобы обеспечить их эффективное применение на практике, вы должны использовать их все одновременно. На рис. 4 изображена диаграмма, которая иллюстрирует взаимодействие всех методик.

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

Рис. 4. Диаграмма, иллюстрирующая взаимодействие всех методик

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