Принципы быстрой разработки ПО - Приемочные тесты

E-mail Печать PDF
Рейтинг пользователей: / 0
ХудшийЛучший 
Индекс материала
Принципы быстрой разработки ПО
Экстремальное программирование
Игра в планирование (Planning Game)
Пользовательские истории
«Билль о правах» заказчика
«Билль о правах» программиста
Притча
xUnit
Приемочные тесты
План рабочего цикла
План выпуска версий
Все страницы

Приемочные тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое самый простой дизайн, который подходит для решения задачи (simlest design that could possibly work)? Согласно Кенту, это дизайн, который:

·                    Обеспечивает корректное срабатывание всех тестов.

·                    Не содержит дублирующегося кода.

·                    Хорошо выражает намерения программиста для каждого из участков кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры