Как работает проектирование при помощи переработки?

 

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

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

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

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

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

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

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

 

Рис. 10. Проект и продукт обладают паралельными подклассами

Этот дизайн нарушает правило Once And Only Once (OAOO) объектно-ориентированного дизайна (код должен присутствовать в системе один раз и только один раз). Чтобы исправить ситуацию, мы начали работать над формированием дизайна, показанного на рис. 11.

 

Рис. 11. Контракт ссылается на класс Function (функция), но не имеет подклассов

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

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

 

Что является самым простым?

 

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

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

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

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

1. Система (как ее код, так и соответствующие тесты) должна выражать собой все, что вы хотите сообщить о ней всем остальным участникам проекта.

2. Система не должна содержать дублирующегося кода (1 и 2 пункты вместе составляют собой правило Once and Only Once).

3. Система должна состоять из наименьшего возможного количества классов.

4. Система должна содержать в себе наименьшее возможное количество методов.

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

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

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

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

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

 

Как это может работать?

 

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

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

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

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

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

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

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

 

Роль рисунков в дизайне

 

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

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

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

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

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

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

Давайте взглянем:

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

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

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

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

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

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

Если вы имеете дело с разновидностью исходного кода, который лучше выражается при помощи картинок, тогда определенно вы должны выражать его, редактировать его и поддерживать его в виде картинок. Хорошим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помощи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это – язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о системе в двух разных синхронизированных между собой представлениях.

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

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

 

Системная архитектура

 

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

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

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

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

 

Глава 18.

Стратегия тестирования

 

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

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

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

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

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

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

Массимо Арнольди (Massimo Arnoldi) пишет:

 

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

Массимо Арнольди (Massimo Arnoldi). Источник: электронная почта.

 

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

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

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

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

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

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

 

Кто пишет тесты?

 

Как я уже говорил в самом начале главы, тесты возникают из двух источников:

• программисты

• заказчики

Программисты пишут тесты для каждого из методов. Тесты, разрабатываемые программистами, называются тестами модулей (unit test). Программист создает тест при следующих условиях:

• если интерфейс метода совершенно неясен, вы пишете сначала тест, а затем метод;

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

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

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

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

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

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

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

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

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

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

 

Другие тесты

 

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

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

• Стресс-тест (stress test) – этот тест разрабатывается для того, чтобы сымитировать наиболее высокую нагрузку на систему. Стресс-тесты применяются для тестирования сложных систем, для которых сложно делать предположения о характеристиках, связанных с производительностью.

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

 

 

Часть 3.

Реализация ХР

 

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

Глава 19.

Внедрение ХР

 

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

За простой и, очевидно, корректный ответ на вопрос о том, как следует внедрять ХР, я хочу поблагодарить Дона Уэллса (Don Wells):

1. Выберите самую неприятную для вас проблему.

2. Решите ее, применяя способ ХР.

3. Когда эта проблема перестает быть самой неприятной для вас, повторите эту последовательность действий с самого начала.

Две очевидные составляющие, с которых можно начать процесс внедрения, – это тестирование и игра в планирование. Очень многие проекты страдают от проблем, связанных с низким качеством кода, а также от дисбаланса полномочий между бизнесом и разработчиками. Вторая книга из серии книг, посвященных ХР, под названием Extreme Programming Applied: Playing to Win (Применение экстремального программирования: игра чтобы победить) будет посвящена именно этим темам, так как с освоения именно этих компонентов ХР удобнее всего приступать к внедрению этой дисциплины.

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

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

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

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