Методология разработки ИС. Экстремальное программирование.

 

Из всех гибких методологий экстремальное программирование (Extreme Programming, XP) — самая известная. Истоки ХР ведут к сообществу разработчиков ПО на языке Smalltalk, а именно к тесному сотрудничеству Кента Бека (Kent Beck) и Уорда Каннингэма (Ward Cunningham) в конце 80-х годов. Существует всего лишь 4 ценности экстремального программирования: простота (Simplicity), общение (Communication), обратная связь (Feedback) и смелость (Courage) (Замечание. В последней редакции XP добавилось еще «уважение»). На реализацию этих основных ценностей и направлены 12 практических методик XP. Рассмотрим их в небольшом приближении.

 

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

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

3. Метафора (Metaphor). Человеку намного легче запомнить отличия между двумя схожими предметами, чем знать строение предмета полностью. Практика «Метафора» предлагает сравнивать систему (или один из ее модулей) с ее аналогами для удобства общения внутри команды и более глубокого понимания системы в целом.

4. Рефакторинг (Refactoring). Процесс постоянной переработки структуры ПО в целях устранения излишней сложности, увеличения понятности кода, повышения его гибкости.

5. Парное программирование (Pair Programming). Периодический просмотр чужого кода положительно влияет на его качество. Этот принцип лежит в основе парного программирования. Заключается оно в том, что два программиста одновременно работают за одним компьютером. Как ни странно, затраты на разработку не увеличиваются в два раза, а остаются приблизительно на том же уровне. С другой стороны при парном программировании повышается качество кода, осуществляется неявная и явная передача знаний, а также проиходит постоянное общение между разработчиками.

6. Совместное владение кодом (Collective Ownership). Чаще всего при разработке програмных продуктов за определенную часть кода отвечает один человек. Отпуск, увольнение или же болезнь одного из программистов может сильно затормозить разработку продукта. Именно поэтому в XP за один кусок кода отвечает не менее двух человек и любой программист может внести изменения в любую часть програмного кода.

7. «Заказчик всегда рядом» (On-site Customer, Whole Team). Представитель заказчика входит в команду разработчика.

8. Стандарты кодирования (Coding Standards). В проекте при написании кода используются стандарты на имена идентификаторов, составление комментариев и т. д. Это в свою очередь обеспечивает успешность таких практик как совместное владение кодом и парное программирование.

9. Разработка через тестирование (Test-Driven Development). Cначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Это позволяет лучше понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.

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

11. Частые небольшие релизы (Small Releases). Первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

12. 40-часовая рабочая неделя (Forty Hour Week). Человек должен отдыхать, именно тогда о достигнет максимальной производительности в рабочее время. Кроме того, сверхурочная работа рассматривается как признак больших проблем в проекте.