Экспериментальное программирование. Основные техники. Достоинства и недостатки ХР

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

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

Основные практики входящие в ХР.

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

2. Частая смена версий.

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

3. Метафора системы должна быть в простом и понятном команде виде описывать основной механизм работы системы.

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

5. Разработка на основе тестирования. Разработчики сначала пишут тесты, потом пытаются писать модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система заработала.

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

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

Риск: человеческий фактор играет определяющую роль. Пара или работает или нет.

8. Коллективное владение кодом. В любое время любой программист может изменить любую часть кода. Никто не должен выделять собственную область ответственности. Риск: без стандартного контроля кода процессор становится не контролированным.

9. Постоянная интеграция. Система собирается и проходит интеграционное тестирование по нескольку раз в день, когда пара прогр-ов закончит реализацию очередной функции.

10. 40 – часовая рабочая неделя. Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа, 2 недели подряд (истощает прогр-тов и уменьшает их уровень работы).

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

12. Использование стандартных кодов. Код рассматривается как важнейшее средство общения внутри команды. Цель введения стандартов кодирования ясность кода, отсутствие дублирования кода и информации.

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

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

Общие замечания:

ХР применима лишь в рамках небольших команд (до 10 прогр-ов). Большой размер усложняет коммуникации, делает невозможным многих указанных практик применение.

Достоинства:

1. Возможность быстро и аккуратно вносить изменения в ПО, в ответ на пожелания заказчиков и изменения требований.

2. Высокое качество кода.

3. Не нужно убеждать заказчика в том, что результат соответствует их ожиданию.

Недостатки:

1. Невыполнимость в таком стиле больших и сложных проектов.

2. Невозможность планировать сроки и трудоемкость проекта на долгую перспективу, а также предсказать результаты длительного проекта в плане соотношения качества результата и затрат времени, ресурсов.

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