В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 15
Текст из файла (страница 15)
15.По утверждению авторов XP, эта методика представляет собой не столько следование каким-тообщим схемам действий, сколько применение комбинации следующих техник. При этом каждаятехника важна, и без ее использования разработка считается идущей не по XP, согласноутверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода, наряду с УордомКаннингемом (Ward Cunningham), и Роном Джефрисом (Ron Jeffries).• Живое планирование (planning game)Его задача — как можно быстрее определить объем работ, которые нужно сделать доследующей версии ПО.
Решение принимается, в первую очередь, на основе приоритетовзаказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного44ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценоктрудоемкости разработки, совместимости с остальными элементами системы и пр.). Планыизменяются, как только они начинают расходиться с действительностью или пожеланиямизаказчика.ИсториииспользованияНовая историяиспользованияСкорость проектаТребования«Вброс»архитектурыМетафорасистемыПланированиеверсииНенадежныеоценкиТестовыесценарииПлан версииУверенныеоценкиОшибкиИтерацияПоследняяверсияПриемочныетестыНебольшиеверсииОдобрениепользователейНовая итерация«Вброс»решенияРисунок 15. Схема потока работ в XP.••••••Частая смена версий (small releases)Самая первая работающая версия должна появиться как можно быстрее и тут же должнаначать использоваться.
Следующие версии подготавливаются через достаточно короткиепромежутки времени (от нескольких часов при небольших изменениях в небольшойпрограмме, до месяца-двух при серьезной переработке крупной системы).Метафора (metaphor) системыМетафора в достаточно простом и понятном команде виде должна описывать основноймеханизм работы системы. Это понятие напоминает архитектуру, но должно гораздопроще, всего в виде одной-двух фраз описывать основную суть принятых техническихрешений.Простые проектные решения (simple design)В каждый момент времени система должна быть сконструирована настолько просто,насколько это возможно.
Не надо добавлять функции заранее — только после явнойпросьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.Разработка на основе тестирования (test-driven development)Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобытесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основныевозможности системы, чтобы можно было увидеть, что система действительно заработала.Постоянная переработка (refactoring)Программисты постоянно перерабатывают систему для устранения излишней сложности,увеличения понятности кода, повышения его гибкости, но без изменений в его поведении,что проверяется прогоном после каждой переделки тестов.
При этом предпочтениеотдается более элегантным и гибким решениям, по сравнению с просто дающими нужныйрезультат. Неудачно переработанные компоненты должны выявляться при выполнениитестов и откатываться к последнему целостному состоянию (вместе с зависимыми от нихкомпонентами).Программирование парами (pair programming)Кодирование выполняется двумя программистами на одном компьютере. Объединение впары произвольно и меняется от задачи к задаче.
Тот, в чьих руках клавиатура, пытаетсянаилучшим способом решить текущую задачу. Второй программист анализирует работу45первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менеепрямые, но более гибкие решения.• Коллективное владение кодом (collective ownership)В любой момент любой член команды может изменить любую часть кода. Никто не долженвыделять свою собственную область ответственности, вся команда в целом отвечает за веськод.• Постоянная интеграция (continuous integration)Система собирается и проходит интеграционное тестирование как можно чаще, понесколько раз в день, каждый раз, когда пара программистов оканчивает реализациюочередной функции.• 40-часовая рабочая неделяСверхурочная работа рассматривается как признак больших проблем в проекте.
Недопускается сверхурочная работа 2 недели подряд — это истощает программистов и делаетих работу значительно менее продуктивной.• Включение заказчика в команду (on-site customer)В составе команды разработчиков постоянно находится представитель заказчика, которыйдоступен в течение всего рабочего дня и способен отвечать на все вопросы о системе.
Егообязанностью являются достаточно оперативные ответы на вопросы любого типа,касающиеся функций системы, ее интерфейса, требуемой производительности, правильнойработы системы в сложных ситуациях, необходимости поддерживать связь с другимиприложениями и пр.• Использование кода как средства коммуникацииКод рассматривается как важнейшее средство общения внутри команды. Ясность кода —один из основных приоритетов. Следование стандартам кодирования, обеспечивающимтакую ясность, обязательно.
Такие стандарты, помимо ясности кода, должны обеспечиватьминимальность выражений (запрет на дублирование кода и информации) и должны бытьприняты всеми членами команды.• Открытое рабочее пространство (open workspace)Команда размещается в одном, достаточно просторном помещении, для упрощениякоммуникации и возможности проведения коллективных обсуждений при планировании ипринятии важных технических решений.• Изменение правил по необходимости (just rules)Каждый член команды должен принять перечисленные правила, но при возникновениинеобходимости команда может поменять их, если все ее члены пришли к согласию поповоду этого изменения.Как видно из применяемых техник, XP рассчитано на использование в рамках небольшихкоманд (не более 10 программистов), что подчеркивается и авторами этой методики.
Большийразмер команды разрушает необходимую для успеха простоту коммуникации и делаетневозможным применение многих перечисленных приемов.Достоинствами XP, если его удается применить, является большая гибкость, возможностьбыстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельныепожелания заказчиков, высокое качество получающегося в результате кода и отсутствиенеобходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших исложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточнодолгую перспективу и четко предсказать результаты длительного проекта в терминахсоотношения качества результата и затрат времени и ресурсов.
Также можно отметитьнеприспособленность XP для тех случаев, в которых возможные решения не находятся сразу наоснове ранее полученного опыта, а требуют проведения предварительных исследованийXP как совокупность описанных техник впервые было использовано в ходе работы напроектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат46работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числеупомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и вдальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократноупоминается в различных источниках как пример использования этой методики [6,7,8].Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом неподтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при ихприменении в достаточно сложных проектах.Проект стартовал в январе 1995 года.
С марта 1996 года, после включения в него Кента Бека,он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и плановпоэтапной реализации функций. Команда разработчиков была сокращена, и в течение примернополугода после этого проект развивался довольно успешно. В августе 1998 года появилсяпрототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, чтопроект завершится в середине 1999 года и результирующее ПО будет использоваться дляуправления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета.
СозданноеПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя былопоказано, что оно справится с данными 30000 работников компании. Человек, игравший рольвключенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, невыдержав нагрузки, и так и не получил адекватной замены до конца проекта.Литература к Лекции 3[1] У. Ройс. Управление проектами по созданию программного обеспечения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
