Бесплатный фрагмент - Введение в экстремальное программирование

ВВЕДЕНИЕ

Экстремальное программирование (eXtreme Programming, XP) — это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уровень риска. От других методик ХР отличается по следующим признакам.

— Благодаря использованию чрезвычайно коротких циклов разработки ХР предлагает быструю, реальную и постоянно функционирующую обратную связь.

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

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

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

— ХР основана на голосовом обмене информацией, тестах и исходном коде. Три этих элемента используются для обмена сведениями о структуре системы и ее поведении.

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

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

— ХР основывается на методиках, которые удовлетворяют как краткосрочным инстинктам отдельных программистов, так и долгосрочным интересам всего проекта в целом.

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

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

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

1. ХР В КРАТКОМ ИЗЛОЖЕНИИ

Экстремальное программирование основано на том, что процесс разработки программного обеспечения — это процесс тесного и интенсивного взаимодействия между людьми. Хорошая методика разработки программ должна с максимальной эффективностью использовать сильные человеческие качества и сглаживать человеческие недостатки. ХР лучше других методик учитывает весь комплекс факторов, оказывающих влияние на людей, занятых разработкой программ. За истекшее десятилетие ХР является наиболее радикальной инновацией в индустрии производства программного обеспечения. В рамках ХР каждому участнику проекта назначается определенная роль с соответствующим набором полномочий. ХР способствует тому, что все участники проекта исполняют назначенные им роли, а следовательно, каждый из них действует в границах своей компетенции. Благодаря этому люди, принимающие участие в проекте, эффективно работают как единая команда. Разработка программного продукта, решающего поставленную бизнес-задачу, выглядит как диалог, в котором принимает участие каждая из заинтересованных сторон. Заказчики формулируют пожелания (stories), назначают им приоритеты (priorities), создают приемочные тесты (acceptance tests), а также снабжают программистов и менеджеров всей необходимой информацией тогда, когда это необходимо. Программисты сообщают заказчикам предварительные оценки трудозатрат (estimates), а позже передают им работающий код в совокупности с тестами модулей (unit test). Менеджеры выступают посредниками — они уравновешивают требования заказчиков и затраты, необходимые для реализации этих требований программистами, кроме того, менеджеры разрешают споры и определяют, какие ресурсы требуются для работы над проектом с учетом постоянно меняющихся бизнес-условий.

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

Кент Бек (Kent Beck) сформулировал ключевые ценности ХР в своей книге «Экстремальное программирование» [3]:

1) Коммуникация (Communication). Если при работе над проектом возникает проблема, зачастую ее причиной является то, что в какой-то момент времени кто-то не сказал кому-то что-то очень важное. В ХР возникновение подобной проблемы маловероятно. Если вы работаете над проектом в стиле ХР, то фактически не можете избежать общения.

2) Простота (Simplicity). ХР всегда предлагает решать задачу самым простым способом из всех возможных (simplest thing that could possibly work). Кент выражает эту мысль следующим образом: «ХР формулирует предположение. ХР предполагает, что лучше сегодня написать самый простой код… чем сегодня потратить время на разработку более сложного кода, а завтра узнать, что этот код вам не нужен».

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

4) Храбрость (Courage). Если вы двигаетесь не с самой высокой скоростью, то вас постигнет неудача. Вы должны обладать храбростью для того, чтобы в нужные моменты времени совершать правильные поступки. Например, вы должны обладать достаточной храбростью для того, чтобы отказаться от кода, на разработку которого вы потратили значительное время. Вы должны обладать храбростью для того, чтобы преодолев половину пути и обнаружив серьезную ошибку, вернуться обратно и начать все с начала.

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

1) Игра в планирование (Planning Game) — диалог между заказчиками и разработчиками с целью определить текущие задачи, приоритеты и сроки реализации.

2) Тестирование (Testing) — как программисты, так и заказчики пишут тесты, позволяющие в любой момент времени убедиться в корректности работы системы.

3) Парное программирование (Pair Programming) — любой код разрабатывается одновременно двумя программистами, работающими на одном компьютере.

4) Рефакторинг (Refactoring) — улучшение кода путем его переработки.

5) Простой дизайн (Simple Design) — постоянное видоизменение дизайна системы с целью его улучшения.

6) Коллективное владение кодом (Collective Code Ownership) — правом вносить изменения в любой код системы обладает любой член команды.

7) Постоянная интеграция (Continuous Integration) — интеграция продукта выполняется постоянно по несколько раз в день.

8) Заказчик на месте разработки (On-Site Customer) — рядом с разработчиками постоянно находится представитель заказчика, который работает вместе с ними.

9) Частые выпуски версий (Small Releases) — каждая следующая версия продукта выходит вскоре после выхода предыдущей версии. Новые версии продукта внедряются в эксплуатацию как можно чаще.

10) 40-часовая рабочая неделя (40-hour Week) — разработчики не должны работать сверхурочно, так как от этого снижается производительность и качество их работы.

11) Стандарты кодирования (Coding Standards) — все участники команды должны придерживаться общих стандартов кодирования.

12) Метафора системы (System Metaphor) — простая аналогия, интуитивно понятная всем участникам проекта, описывающая собой внутреннее строение и функционирование системы.

Для многих все это покажется знакомым. Здесь нет ничего нового. Эти практики используются в индустрии разработки программного обеспечения на протяжении многих лет. Почему же в ХР эти практики приводят к значительно более впечатляющим результатам? Дело в том, что слово «экстремальное» в названии методики ХР означает в основном две вещи:

1) ХР использует каждую из этих практик в «экстремальной» форме, то есть с максимально возможной интенсивностью.

2) ХР комбинирует эти практики таким образом, что величина результатов превышает величину суммы составляющих.

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

Давайте подробнее рассмотрим каждую из 12 практик и роль, которую они играют в ХР.

1.1. Игра в планирование (Planning Game)

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

Команда разработчиков:

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

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

— распределяет задачи между членами команды;

— оценивает риск, связанный с реализацией каждого из пожеланий;

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

Заказчик:

— определяет объем работ, то есть набор пожеланий для выпуска и набор пожеланий для итерации;

— определяет дату завершения работы над выпуском;

— назначает приоритеты, то есть, исходя из полезности различных функций с точки зрения бизнеса, определяет, какие из функций продукта должны быть реализованы в первую очередь.

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

1.2. Тестирование (Testing)

В ХР используются две разновидности тестирования: тестирование модулей (unit testing) и приемочное тестирование (acceptance testing).

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

Если предположить, что для разработки команда использует объектно-ориентированный язык, то разработчики пишут тесты для каждого метода, корректность работы которого может быть нарушена. Разработка тестов для метода выполняется до того, как будет написан рабочий код этого метода. После того как разработаны все возможные тесты, разрабатывается код метода. Реализация метода должна быть такой, чтобы обеспечить выполнение всех тестов и не более того. Для многих такой подход кажется весьма странным, однако он вполне оправдан. Благодаря тому, что код тестов пишется до того, как разрабатывается код метода, вы получаете:

— наиболее полный набор всевозможных тестов;

— наиболее простой код, который (скорее всего) реализует заданную функциональность;

— четкое представление о том, какую задачу решает код.

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

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

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

1.3. Программирование парами (Pair Programming)

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

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

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

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

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

— происходит постоянная перепроверка (review) чужого кода: один партнер пишет код, другой просматривает этот код.

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

1.4. Рефакторинг (Refactoring)

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

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

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

1.5. Простой дизайн (Simple Design)

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

Что такое самый простой дизайн, который подходит для решения задачи? Согласно Кенту, это дизайн, который:

1) обеспечивает корректное срабатывание всех тестов;

2) не содержит дублирующегося кода;

3) хорошо выражает намерения программиста для каждого участка кода;

4) включает наименьшее количество классов и методов.

Если система обладает простым дизайном, то это не значит, что она маленькая или тривиальная. Дизайн должен быть настолько простым, насколько это возможно, и при этом он должен решать поставленную задачу. Не следует включать в дизайн дополнительные возможности, которые не используются. Мы называем подобные неиспользуемые вещи YAGNI, что означает You Ain’t Going to Need It (Вам это не потребуется). Не позволяйте YAGNI отбирать у вас шансы на успех.

1.6. Коллективное владение кодом
(Collective Code Ownership)

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

Но не возникает ли при этом каких-либо проблем? Ведь если кто угодно будет как угодно менять код системы в каком угодно месте, неизбежно возникнет хаос. Для решения этой проблемы в ХР действует простое правило: «You break it, you fix it» (Кто сломал, тот и исправляет). Если модифицировав код, программист нарушил работоспособность системы, то он обязан восстановить работоспособность. Иными словами, то, что код принадлежит всем, вовсе не означает, что код не принадлежит никому. Когда код не принадлежит никому, это означает, что никто не несет ответственности за его работоспособность. В ХР код принадлежит всем, это значит, что если вы решили модифицировать код, вы несете ответственность за его корректную работу. Это значит, что все тесты модулей должны корректно срабатывать как до модификации, так и после модификации. Если, попытавшись улучшить код, вы нарушили корректную работу одного или нескольких тестов, вы обязаны восстановить корректное срабатывание всех тестов вне зависимости от того, в каком месте системы вы осуществляете модификацию. Это невозможно без соблюдения строгой дисциплины.

1.7. Постоянная интеграция (Continuous Integration)

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

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

1.8. Заказчик в команде (On-Site Customer)

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

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

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

1.9. Частые выпуски версий (Small Releases)

Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.

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

1.10. 40-часовая рабочая неделя (40-hour Week)

Кент говорит, что желает быть «…свежим и энергичным каждое утро, равно как и уставшим и удовлетворенным каждый вечер» [3]. Этого можно достичь в случае, если вы будете работать не более 40 ч в неделю. Принцип более важен, чем конкретное количество часов. Слишком длительное «подливание масла в огонь» негативно влияет на производительность разработчиков. Уставшие разработчики допускают большое количество ошибок, что в перспективе еще больше замедлит их работу.

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

1.11. Стандарты кодирования (Coding Standards)

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

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

2) обеспечивается эффективное выполнение остальных практик.

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

1.12. Метафора системы (System Metaphor)

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

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

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

1.13. ХР — это комбинация практик

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

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

2. ПРАВИЛЬНЫЙ НАСТРОЙ МЫСЛЕЙ

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

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

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

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

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

2.1. Организационная неизбежность

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

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

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

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

2.2. Ваша роль

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

В 1965 году Джон Уильям Уорд (John William Ward) писал: «В наше время человек, принимающий на себя реальный риск, вовсе не является выдающимся деятелем. Он вовсе не герой. Он просто один из тех, кто старается обеспечить работу существующих учреждений» [2]. Это именно та роль, которую вы должны играть в вашей компании в случае, если в ней используется традиционный подход к разработке программ. Вы можете не только предложить изменить существующий порядок вещей, но и реализовать предлагаемое вами на практике. Как это сделать? Об этом рассказывается в следующем разделе.

3. ВНЕДРЕНИЕ И АДАПТАЦИЯ ХР