Экстремальное тестирование. Унифицированный процесс разработки и экстремальное программирование

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

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

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

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

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

тестирование модулей (unit testing);
приёмочное тестирование (acceptance testing).

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

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

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

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

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

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

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

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

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

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

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

Рефакторинг

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

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

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

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

Простота дизайна

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

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

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

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

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

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

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

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

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

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

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

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

Литература

Кент Бек: Экстремальное программирование - Питер, 2002, ISBN 5-94723-032-1 .
Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование - Питер, 2003, ISBN 5-318-00111-4 .
Кент Бек: Экстремальное программирование: разработка через тестирование - Питер, 2003, ISBN 5-8046-0051-6 .
Кен Ауэр, Рой Миллер: «Экстремальное программирование: постановка процесса с первых шагов и до победного конца» - Питер, 2003, ISBN 5-318-00132-7 .

См. также

Ссылки

Ward Cunningham Wiki (англ.) - «передний край» XP.
XProgramming.com (англ.) - сайт Рона Джеффриза: статьи и ресурсы по XP и смежным вопросам, обзоры книг.
Extreme Programming: A gentle introduction (англ.) - «Ненавязчивое введение в XP» Дона Уэллса.
MAXKIR.COM (рус.) - переводы статей отцов-основателей и идеологов XP
www.agiledev.ru (рус.) - Сайт гибких методик разработки
TopCoder (англ.) - соревнование по спортивному программированию
Электронная библиотечка книг по экстремальному программированию (рус.)
Экстремальное программирование - реальность и мифы (рус.)
Тестирование в свете Экстремального Программирования. Часть 1 (рус.)
IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения? (рус.)

Разработка программного обеспечения
Известные деятели
Процесс
Концепции
Направления
Модели разработки
Другие модели
Прочее

Wikimedia Foundation . 2010 .

Смотреть что такое "Экстремальное программирование" в других словарях:

экстремальное программирование - Одна из методологий разработки ПО. Тематики информационные технологии в целом EN extreme programmingXP … Справочник технического переводчика

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

Экстремальное управление проектами (англ. Extreme project management, XPM) метод управления очень сложными или неопределёнными проектами. От традиционных методов управления проектами XPM отличается открытым, гибким и… … Википедия

И другие.

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

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

1 / 5

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

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

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

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

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

Субтитры

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

Короткий цикл обратной связи (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, в некотором смысле, позволяет писать код, более удобный в использовании - потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.

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

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

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

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

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

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

Рефакторинг

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

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

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

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

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

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

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

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

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

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

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

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

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

Посвящается Синди: крыльям моей души

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

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

ISBN 978-0321146533 англ.

ISBN 978-5-496-02570-6

Предисловие

Чистый код, который работает (clean code that works), – в этой короткой, но содержательной фразе, придуманной Роном Джеффризом (Ron Jeffries), кроется весь смысл методики разработки через тестирование (Test-Driven Development, TDD). Чистый код, который работает, – это цель, к которой стоит стремиться потому, что

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

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

Улучшает жизнь пользователей ваших программ;

Позволяет вашим коллегам рассчитывать на вас, а вам – рассчитывать на них;

Писать такой код приятнее.

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

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

Любое дублирование устраняется.

Два простых правила, не правда ли? Однако они генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

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

Мы сами пишем тесты, так как не можем ждать, что кто-то другой напишет тесты для нас;

Наша среда разработки должна быстро реагировать на небольшие модификации кода;

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

Два упомянутых правила TDD определяют порядок этапов программирования.

1. Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.

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

3. Рефакторинг – устраните из написанного кода любое дублирование.

Красный – зеленый – рефакторинг – это мантра TDD.

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

При достаточно низкой плотности дефектов команда контроля качества (Quality Assurance, QA) сможет перейти от реагирования на ошибки к их предупреждению;

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

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

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

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

Храбрость

TDD – это способ управления страхом в процессе программирования. Я не имею в виду страх падения со стула или страх перед начальником. Я имею в виду страх перед задачей, «настолько сложной, что я пока понятия не имею, как ее решить». Боль – это когда природа говорит нам: «Стоп!», а страх – это когда природа говорит нам: «Будь осторожен!» Осторожность – это совсем не плохо, однако помимо пользы страх оказывает на нас некоторое негативное влияние:

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

Страх заставляет нас меньше общаться;

Страх заставляет нас пугаться отзывов о нашей работе;

Страх делает нас раздражительными.

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

Не пытаться предсказать будущее, а немедленно приступить к практическому изучению проблемы;

Не отгораживаться от остального мира, а повысить уровень коммуникации;

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

(с раздражением вы должны справиться самостоятельно).

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

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

Читатели книги Extreme Programming Explaine , должно быть, обратили внимание на разницу в тоне между экстремальным программированием (Extreme Programming, XP) и разработкой через тестирование (Test-Driven Development, TDD). В отличие от XP методика TDD не является абсолютной. XP говорит: «чтобы двигаться дальше, вы обязаны освоить это и это». TDD – менее конкретная методика. TDD предполагает наличие интервала между принятием решения и получением результатов, и предлагает инструменты управления продолжительностью этого интервала. «Что, если в течение недели я буду проектировать алгоритм на бумаге, а затем напишу код, использовав подход “сначала тесты”? Будет ли это соответствовать TDD?» Конечно, будет. Вы знаете величину интервала между принятием решения и оценкой результатов и осознанно контролируете этот интервал.

Большинство людей, освоивших TDD, утверждают, что их практика программирования изменилась к лучшему. Инфицированные тестами (test infected) – такое определение придумал Эрих Гамма (Erich Gamma), чтобы описать данное изменение. Освоив TDD, вы обнаруживаете, что пишете значительно больше тестов, чем раньше, и двигаетесь вперед малюсенькими шагами, которые раньше показались бы вам бессмысленными. С другой стороны, некоторые программисты, познакомившись с TDD, решают вернуться к использованию прежних практик, зарезервировав TDD для особых случаев, когда обычное программирование не приводит к желаемому прогрессу.

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

Экстремальное программирование - или, сокращенно, 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 имеет свою схему процесса разработки (хотя, вообще говоря, широко используемое понимание "процесса разработки" как достаточно жесткой схемы действий противоречит самой идее "живости" разработки), приведенную на рис.1.

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

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

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

Рис.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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