XP: экстремальное программирование на практике. Методики и принципы экстремального программирования

И другие.

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

Энциклопедичный YouTube

1 / 5

Экстремальное программирование (XP) - основные приемы

Hexlet Webinar #6: экстремальное программирование

Life Tips. Зачем участвовать в соревнованиях по программированию?

032. Парное программирование - Сергей Бережной

Канал экстремального программирования v. 2.0

Субтитры

Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine-scale feedback)
- Разработка через тестирование (Test-driven development)
- Игра в планирование (Planning game)
- Заказчик всегда рядом (Whole team, Onsite customer)
- Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
- Непрерывная интеграция (Continuous integration)
- Рефакторинг (Design improvement, Refactoring)
- Частые небольшие релизы (Small releases)
Понимание, разделяемое всеми
- Простота (Simple design)
- Метафора системы
- Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
- Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищённость программиста (Programmer welfare):
- 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

Тестирование

XP предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:

юнит-тестирование модулей;

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

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

Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development - разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл. TDD, в некотором смысле, позволяет писать код, более удобный в использовании - потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.

Игра в планирование

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

Заказчик всегда рядом

«Заказчик» в XP - это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Парное программирование

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

Непрерывная интеграция

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

Рефакторинг

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

Частые небольшие релизы

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

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

Простота проектирования

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

Метафора системы

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

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

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

Стандарты кодирования

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

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

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

Коллективное владение

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

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

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

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

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

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

Экстремальное программирование предлагает готовое решение: делайте все максимально просто, держите заказчика при себе или сами держитесь при заказчике, позвольте ему активно следить за процессом разработки, приветствуйте изменения - и успех практически обеспечен.

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

Экстремальный цикл

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

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

Как следствие постоянно изменяющихся требований следует другой принцип - позднее принятие решений.

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

Как можно более раннее формирование базовой архитектуры.

Использование компонентной архитектуры.

Прототипирование, инкрементная разработка и тестирование.

Регулярные оценки текущего состояния.

Управление изменениями, постоянная отработка изменений извне проекта.

Нацеленность на создание продукта, работоспособного в реальном окружении.

Нацеленность на качество.

Адаптация процесса под нужды проекта.

Экстремальное программирование

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки , появившемся в 2000 году.

Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.

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

Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.

Отработка изменений более важна, чем следование планам.

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

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

Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широко используемое понимание «процесса разработки» как достаточно жесткой схемы действий противоречит самой идее «живости» разработки), приведенную на Рис. 15.

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) , одного из авторов этого подхода, наряду с Уордом Каннингемом (Ward Cunningham), и Роном Джефрисом (Ron Jeffries).

Живое планирование (planning game)

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

				Тестовые
		использования		сценарии
			Новая история
	Требования		использования
	Требования		Скорость проекта

	Метафора		План версии
		Планирование	План версии	Итерация	Приемочные	Небольшие
архитектуры				Последняя
						Одобрение
						пользователей
Ненадежные			Уверенные	Новая итерация

«Вброс» решения

Рисунок 15. Схема потока работ в XP.

Частая смена версий (small releases)

Метафора (metaphor) системы

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

Простые проектные решения (simple design)

В каждый момент времени система должна быть сконструирована настолько просто, насколько это возможно. Не надо добавлять функции заранее - только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

Разработка на основе тестирования (test-driven development)

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

Постоянная переработка (refactoring)

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

Программирование парами (pair programming)

первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менее прямые, но более гибкие решения.

Коллективное владение кодом (collective ownership)

В любой момент любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности, вся команда в целом отвечает за весь код.

Постоянная интеграция (continuous integration)

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

40-часовая рабочая неделя

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

Включение заказчика в команду (on-site customer)

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

Использование кода как средства коммуникации

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

Открытое рабочее пространство (open workspace)

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

Изменение правил по необходимости (just rules)

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

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

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

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

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат

работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики . Приведенные ниже данные собраны на основе упомянутых статей , за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.

Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.

Литература к Лекции 3

У. Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.

А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, 2002.

Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/ TheSpiritoftheRUPDec01.pdf

К. Бек. Экстремальное программирование. СПб.: Питер, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler goes to “Extremes”. Distributed Computing, 10/1998.

A. Cockburn. Selecting a Project’s Methodology. IEEE Software, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Strengthening the Case for Pair Programming. IEEE Software 4/2000.

G. Keefer. Extreme Programming Considered Harmful for Reliable Software Development. AVOCA Technical Report, 2002.

Доступен как http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf .

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Содержание

Введение
1. Что такое ХР?
3.1 Основные приёмы XP
4. Достоинства и недостатки
5. История использования
Заключение

Введение

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

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

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

1. Что такое ХР?

Экстрема м льное программи м рование (англ. Extreme Programming , XP ) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

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

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

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

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

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

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

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

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

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

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

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

2. С чего начинается экстремальное программирование

С чего начинается экстремальное программирование? С понимания того, что типичное положение отечественного разработчика программного обеспечения обязывает максимально снижать стоимость разработки. А для этого необходимо интенсивно сотрудничать с заказчиком, понимать его интересы и, в конце концов, сделать именно то, чего он хочет: не больше и не меньше.

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

Экстремальное программирование предлагает готовое решение: делайте все максимально просто, держите заказчика при себе или сами держитесь при заказчике, позвольте ему активно следить за процессом разработки, приветствуйте изменения - и успех практически обеспечен.

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

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

3. Техники XP

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО "снизу вверх". Этот подход является примером так называемого метода "живой" разработки (Agile Development Method). В группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

Основные принципы "живой" разработки ПО зафиксированы в манифесте "живой" разработки, появившемся в 2000 году.

· Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.

· Работающая программа более важна, чем исчерпывающая документация.

· Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.

· Отработка изменений более важна, чем следование планам.

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

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

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

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck), одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).

· Живое планирование (planning game )

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

Рис .1 Схема потока работ в XP

· Частая смена в ерсий (small releases )

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

· Метафора (metaphor ) системы

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

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

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

· Простые проектные решения (simple design )

В каждый момент времени система должна быть сконструирована настолько просто, насколько это возможно. Не надо добавлять функции заранее - только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

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

· Разработка на основе тестирования (test - driven development )

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

В XP особое внимание уделяется двум разновидностям тестирования:

ь тестирование модулей (unit testing);

ь приемочное тестирование (acceptance testing).

экстремальное программирование программное обеспечение

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

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

Для XP более приоритетным является подход называемый TDD (Test Driven Development), сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.

· Постоянная переработка (refactoring )

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

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

· Программирование парами (pair programming )

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

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

· Коллективное владение кодом (collective ownership )

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

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

· Постоянная интеграция (continuous integration )

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

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

· 40-часовая рабочая неделя

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

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

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

· Включение заказчика в команду (on - site customer )

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

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

· Использование кода как средства коммуникации

· Открытое рабочее пространство (open workspace )

· Изменение правил по необходимости (just rules )

3.1 Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:

· Короткий цикл обратной связи (Fine scale feedback)

o Разработка через тестирование (Test driven development)

o Игра в планирование (Planning game)

o Заказчик всегда рядом (Whole team, Onsite customer)

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

· Непрерывный, а не пакетный процесс

o Непрерывная интеграция (Continuous Integration)

o Рефакторинг (Design Improvement, Refactor)

o Частые небольшие релизы (Small Releases)

· Понимание, разделяемое всеми

o Простота (Simple design)

o Метафора системы (System metaphor)

o Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

o Стандарт кодирования (Coding standard or Coding conventions)

· Социальная защищенность программиста (Programmer welfare):

o 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Игра в планирование

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

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

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

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

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

4. Достоинства и недостатки

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

5. История использования

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Приведенные ниже данные иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.

Заключение

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

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

Размещено на Allbest.ru

Подобные документы

Анализ этапов и особенностей разработки оптимальной и функциональной ARIS-модели - программного продукта компании IDS Scheer для моделирования бизнес-процессов компании. Изучение основных концепций, методологий и подходов экстремального программирования.

контрольная работа , добавлен 04.06.2011

Основные этапы разработки программного обеспечения (пакета программ), анализ требований к системе. Метод пошаговой детализации. Языки программирования низкого уровня и высокого уровня (императивные, объектно-ориентированные, функциональные, логические).

презентация , добавлен 13.10.2013

Язык разработки, среда реализации, инструменты разработки. Особенности виртуальной среды реализации программ и их учет в разработке программного продукта. Системные макросы и их применение в текстах разработки. Средства визуального программирования.

учебное пособие , добавлен 26.10.2013

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

презентация , добавлен 30.04.2014

Машинные коды и ассемблер. Первые языки программирования высокого уровня. Язык программирования FORTRAN. Достоинства и недостатки ALGOL. Научные и бухгалтерские программы. Основные принципы, которые соблюдались при создании языка программирования Basic.

курсовая работа , добавлен 21.06.2014

Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.

курсовая работа , добавлен 14.12.2012

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

презентация , добавлен 14.08.2013

Международный стандарт на язык программирования Паскаль. Приемы объектно-ориентированного программирования в Турбо Паскале. Символы языка, его алфавит. Этапы разработки программы. Понятие алгоритмов и алгоритмизации. Структура программ на Паскале.

курсовая работа , добавлен 28.02.2010

Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.

дипломная работа , добавлен 13.07.2011

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

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

Прежде всего, что такое XP? В Интернете можно найти массу определений и описаний
этого термина. В принципе, каждое из них более-менее адекватно отражает суть
явления, но многообразие определений может запутать разработчика. Поэтому нужно
понимать, что XP это набор методик, выработанных для того, что бы подчинить
процесс разработки программного обеспечения четырем базовым принципам. А именно:

общение;
простота;
обратная связь;
храбрость.

Обычно, в материалах по XP эти методики конкретизируются. Вот наиболее
типичный их перечень:

Игра в планирование;
Тестирование до начала разработки;
Парное программирование;
Постоянная переработка;
Простота разработки;
Коллективное владение кодом;
Продолжающаяся интеграция;
Заказчик на рабочей площадке;
Быстрый выпуск версий;
Сорокачасовая рабочая неделя;
Стандарты кодирования;
Метафора системы.

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

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

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

Метафора системы. Разрабатываемые продукты или фрагменты кода сравниваются, с
какими-либо аналогичными продуктами или явлениями. Строятся метафоры. Это
упрощает понимание задачи, а, соответственно, ускоряет разработку.

Но так же нужно понимать, что в том случае, если в силу каких-либо причин
какая-либо из этих методик начинает идти вразрез с основными принципами XP, а
такие ситуации вполне возможны, то от нее следует отказаться.

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

Теперь давайте посмотрим, как подходы ХР могут быть использованы на практике в
наших условиях. Одной из моих на работе задач является автоматизация учебного
процесса. Собственно говоря, я на протяжении достаточно большого отрезка времени
занимаюсь написанием приложения, осуществляющего (по крайней мере по замыслу
автора:)) комплексное решение этой проблемы. Бюджет у проекта мизерный, а объем
работ – приличный. Еще одним, чуть ли не решающим фактором было постоянное
видоизменение предметной области. Регулярно меняются формы отчетной
документации, и методика их получения. Сложилась ситуация, когда проект перестал
успевать за требованиями пользователя. И однажды наступил момент, когда в силу
объективных и субъективных причин, разработку можно было смело хоронить. Однако
неожиданно передо мной была поставлена конкретная задача определения
загруженности аудиторного фонда на семестр. К этому моменту из трех участников
проекта остался я один, а данная подсистема не была реализована и реализация ее
даже не стояла в ближайших планах развития проекта. О таких мелочах как
грамотная постановка задачи, подсчет трудоемкости работ, выделении
дополнительных ресурсов никто даже и не задумался. На выполнение задачи было
отведено две недели. При этом мои аргументы, касающиеся невозможности выполнения
данной задачи не рассматривались в принципе. Первым моим решением было подыскать
себе другого работодателя, так как за две недели я был должен написать не только
модуль анализа загруженности аудиторного фонда, но и систему ввода расписания
занятий, контроля накладок и многое другое. Автономно, данная задача не решается
в принципе — нужны исходные данные. И не просто исходные данные, а корректные
исходные данные, откуда и вытекают все вышеперечисленные задачи. Тем не менее,
не знаю почему, но я взялся за решение этой задачи.

Естественно, что говорить о разработке классическими методами в данном случае
неуместно. Вот здесь-то и пригодились подходы ХР. Общее представление о задаче я
уже имел, однако имелось множество нюансов, которые потенциально могли
значительно увеличить объем работ. Начал работу я с того, что набрал номер
учебного отдела и стал засыпать снявшего трубку массой вопросов, ответы на
которые я не мог найти самостоятельно или в которых я не был уверен.
.
Я запустил Rational Rose и приступил к составлению модели. К концу рабочего дня
я набросал модель, показавшуюся мне более-менее адекватной. После работы я
предпринял еще один шаг, отвечающий идеологии ХР. Я вытащил своего приятеля,
работающего в учебном отделе попить пива. В процессе этого, важного во всех
отношениях мероприятия, я изложил ему свое виденье программы, ее интерфейса и
логики работы. Он, в свою очередь, принимался рассказывать о необходимости
решения некоторых локальных подзадач. К вечеру я уже более четко уяснил, что же
все-таки нужно сделать в рамках данного проекта (я уже не сомневался, что задачу
следует рассматривать как отдельный проект). Тем не менее, не был решен еще один
не маловажный вопрос – выбор средств разработки. Когда происходили описываемые
события, я начинал активно изучать MDA технологию. Вкратце, суть ее такова:
фрагменты кода приложения и структуры данных генерируются автоматически, исходя
из UML модели, что позволяет существенно сократить время разработки. В рамках
данной статьи я не буду детально описывать принципы работы MDA, но хочу
акцентировать ваше внимание на том, что использование этой технологии полностью
отвечает «духу XP». Связано это с тем, что одним из условий, при котором
методики XP будут успешно работать, это снижение стоимости изменений, вносимых в
приложение на поздних стадиях разработки. Среди факторов, способствующих
достижению этого, не маловажным является использование различных новых
технологий программирования. Замечу, что именно простота рефакторинга MDA
приложений является одним из основных преимуществ этой технологии. Вообще, на
сегодня существует достаточно много реализаций MDA, я остановил свой выбор на
Bold for Delphi.

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

Альтернативным вариантом было написание «обычного» Delphi приложения. Я запустил
ICQ и написал сообщение своему знакомому – адепту Bold. После того, как я
вкратце изложил ему суть проблемы, я спросил, как бы он на моем месте поступил.
Он ответил примерно следующим образом: «Либо погружаться с головой в Bold, либо
ты никогда не освоишь его. Сделать серьезный проект – лучший способ изучить
технологию». Собственно, другого ответа я и не ожидал.

С утра я взял существующую модель и начал строить приложение. Именно, строить. К
кодированию я не приступал, а просто набросал пользовательский интерфейс, многие
элементы которого практически сразу заработали. На перекур я старался выходить в
компании сотрудников учебного отдела, это позволяло мне затащить очередную
«жертву» к экрану своего монитора и (не без некоторой доли гордости) показывал
промежуточные результаты. Таким образом, реализовывался принцип обратной связи.
Вы можете справедливо заметить: «А как же парное программирование?». Да,
действительно, в качестве программиста в проекте участвовал я один. Но тут я
упомяну еще об одном счастливом стечении обстоятельств. В тот период времени,
когда происходили описываемые события, я, совместно с группой разработчиков —
энтузиастов развивал Интернет-проект, посвященный, именно MDA. И вот, когда я
подошел к самому сложному месту в своей разработке, этот проект принес
совершенно неожиданные результаты.

В течение нескольких дней я писал код процедуры, реализующей отображение занятий
на экране. Стандартные элементы управления не позволяли вывести на экран все
данные, в той форме, в которой они обычно представляются. Мне же хотелось, что
бы конечный пользователь хотя бы приблизительно понимал, что же делает программа
и как с ней работать. Я написал свой компонент, на основе обычного TStringGrid.
Я не был уверен в том, что это было хорошее решение, но код работал. В форуме
нашего проекта я изложил свое решение, ожидая получить какую-то оценку в течение
достаточно долгого промежутка времени. Однако буквально через 15-20 минут пришел
первый ответ. Предлагался альтернативный вариант решения, а еще через 10 минут
пришел тестовый пример, да не один, а сразу два, от двух авторов. Если
задуматься над тем, почему разработчики, с таким энтузиазмом принялись решать
чужую задачу, то можно прийти к простому выводу. Во-первых, им просто было
интересно найти некоторое универсальное решение, которое затем можно
использовать в своих проектах. А во-вторых, им был интересен сам процесс
общения. Надо отметить, что с таким же энтузиазмом решались и другие задачи
различного уровня сложности. Конечно, это не является парным программированием в
обычном понимании. Скорее это некий суррогат, но, тем не менее, в этом есть и
свои плюсы. Скажем, все высказываемые мысли, и идеи автоматически
документировались, и к ним можно было обратиться в любой момент.

На тестах я хотел бы остановиться отдельно. Как рекомендует в своей книге
«Экстремальное программирование» Кент Бек, тесты должны писаться заранее. Более
того, у автора это выглядит примерно так. Имеется специальная программа,
написанная самим разработчиком, при нажатии на одну из кнопок которой
запускаются все тесты, а в итоге на экране появляется зеленая «лампочка» в
случае позитивного результата и красная в противном случае. Меня такое описание
несколько обескуражило. Согласитесь, сложно себе представить, каким образом
можно написать программу, имитирующую действия пользователя, абсолютно во всех
ситуациях.

Как я уже говорил, я не старался строго придерживаться методик экстремального
программирования. А в прочитанных мною книгах недвусмысленно утверждалось, что
написание теста – один из наиболее важных моментов в XP, и без этого остальные
методики сработать не должны. Почему же в итоге я достиг положительного
результата? Все оказалось достаточно просто. Ответить на этот вопрос мне помог
именно этот пример с зелеными и красными лампочками. Дело в том, что в Bold
имеется возможность показать, соответствует – ли данный объект модели. И
делается это как раз с помощью подобных «лампочек». Буквально две строки,
которые я почти сразу вставил в код приложения, позволяли мне увидеть, в каком
месте происходит несоответствие (если таковое имеется). Именно это и заменило
мне тестирование. Возможно, что такой подход и не совсем соответствовал
оригинальной идее «тестирования до начала разработки», но это сработало.

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

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

http://xprogramming.com.ua/ — мир
экстремального программирования

http://www.xprogramming.ru/ —
экстремальное программирование по русски

http://www.maxkir.com/ — о разработке
программного обеспечения

http://xprogramming.com/ — сайт
идеолога XP Рона Джеффриса