CC BY
226
УДК 372.8
ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ КАК ГИБКАЯ МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
© 2009 П. В. Конников1, В. А. Кудинов2
1 аспирант каф. программного обеспечения и администрирования информационных систем e-mail: konnikov@gmail.com
2 канд. пед. наук, проректор по НИР e-mail: kudinovva@yandex.ru
Курский государственный университет
Методология разработки программного обеспечения «Экстремальное программирование» обратила на себя значительное внимание в последние годы.
Важным преимуществом экстремального программирования является его гибкость в отношении простоты управления меняющимися требованиями заказчика. Мы рассматриваем практики экстремального программирования в контексте преподавания дисциплин программной инженерии в вузе, пытаемся оценить влияние практик экстремального программирования на овладение инженерными навыками для разработки программного обеспечения.
Ключевые слова: гибкие методы, экстремальное программирование,
рефакторинг, модульное тестирование.
Понятие «Экстремальное программирование» было введено в 1996 году. Экстремальное программирование является упрощенной, но в то же время соответствующей полному жизненному циклу программного обеспечения методологией разработки программного обеспечения (см. Библ. список в конце статьи). В последние годы интерес промышленных производителей ПО к использованию этой методологии стремительно растет. Также растет интерес к этому вопросу у преподавателей информатики и информационно-коммуникационных технологий по всему миру. Большой интерес вызывают вопросы, связанные с применением экстремального программирования в образовательной среде. А некоторые преподаватели уже пытаются внедрять эту методологию в различные курсы для обучения инженеров-программистов в вузе.
Недавно экстремальное программирование обратило на себя пристальное внимание в сообществе разработчиков программного обеспечения. Интерес со стороны сообщества разработчиков был вызван восхвалением преимуществ этой практики в отношении мотивации сотрудников, сокращения сроков проекта и повышения удовлетворенности заказчиков. Перечислим обзор практик относящихся к экстремальному программированию. Каждая из практик будет кратко описана ниже.
Метафора Модульное тестирование
Совместное владение кодом Функциональный тест
Простой дизайн Парное программирование
Рефакторинг Стандарты кодирования
Небольшие релизы Открытое рабочее пространство
Непрерывная интеграция 40-часовая рабочая неделя
Доступный заказчик Игра в планирование
Метафора. Подход экстремального программирования предполагает, что каждое программное приложение должно иметь концептуальную целостность, основанную на простой метафоре, которая раскрывает сущность того, как работает система. Например, один большой проект представлял собой систему платежей для крупной автомобильной компании. Метафора для этого проекта заключалась в том, что платежная система была похожа на линию сборки, где единицы времени были заменены на денежные единицы, а когда все единицы были собраны, был готов платежный чек.
Совместное владение кодом. В команде разработчиков, которая применяет методологию экстремального программирования, за каждый отдельно взятый участок программного кода несет ответственность не только разработавший его программист. Программный код вносится в коллективную базу кода всей команды. Как только часть кода попадает в общую базу кода, каждый член команды имеет доступ ко всему коду и несет ответственность за весь код в целом. Впоследствии каждый член команды может менять любой участок кода, не спрашивая у кого-либо разрешения.
Простой дизайн. Экстремальное программирование стремится к максимально простому проектированию. В нем подчеркивается, что программисты не должны пытаться предвидеть будущие требования и проектировать программу соответствующим образом. Они основываются на двух простых принципах в своей философии проектирования: «Вам это не понадобится» (“You aren’t gonna need it”) и «Выбирать самый простой вариант, который может сработать».
Рефакторинг. Рефакторинг - это процесс улучшения структуры программного кода во время работы над его функциональностью. Рефакторинг ведет к изменению структуры кода, не меняя при этом его функциональности. Принципы экстремального программирования рекомендуют применять рефакторинг кода регулярно и не отказываться от него.
Небольшие релизы. Экстремальное программирование усиливает значение итеративной разработки, акцентируя внимание на коротких релизах длительностью З-4 недели. В конце каждого релиза заказчик просматривает продукт в его текущем состоянии, указывает на присутствующие ошибки, корректирует и добавляет требования новые.
Непрерывная интеграция. Задания программистам могут быть разбиты на маленькие конкретные задачи, которые могут быть выполнены не более чем за один день. Когда каждая задача выполнена, ее решение интегрируется в единую базу программного кода, после чего происходит сборка программного продукта и прогоняются все тесты. В результате мы получаем много сборок программного продукта каждый день, что дает в каждый момент времени полностью работающий продукт.
Доступный заказчик. Заказчики всегда легко доступны для разработчиков для задач уточнения и проверки требований во время процесса реализации. Предпочтительнее заказчик локальный, а не удаленный.
Модульное тестирование. До того как будет разработан программный код приложения, должны быть разработаны достаточно большие наборы автоматизированных тестов так называемого «белого ящика». Эти автоматизированные тесты также добавляются в общую базу программного кода. До того как интегрировать свой код в общую базу, программист должен добиться срабатывания всех тестов, написанных им в данную сессию, и всех тестов в общей кодовой базе в целом. Это может гарантировать, что новый код реализует новую функциональность, не нарушая работы какого-либо другого участка программного кода.
Функциональные тесты. Традиционно техники управления проектами основывались на оценке самого разработчика, того, как много задач он выполнил. В отличие от такого подхода, методология экстремального программирования использует набор функциональных тестов для вычисления стадии завершения проекта. Экстремальное программирование называет такую оценку «Скорость проекта». Наборы функциональных тестов основаны на сценариях работы будущей системы, которые определяет заказчик. Когда набор функциональных тестов успешно сдан, можно считать, что указанная функциональность была корректно реализована. Стадия завершенности проекта выражается в процентном отношении общего количества сданных функциональных тестов. Члены команды разработчиков могут однозначно вычислить эту оценку, которая является независимой и точной.
Парное программирование. Все время работы над проектом за одним компьютером работают два программиста, совместно обсуждая вопросы проектирования, алгоритмы, программный код или тесты.
Стандарты кодирования. Для того чтобы разработчики могли легче понимать программный код друг друга, необходимо согласовать стандарты кодирования и неукоснительно им следовать. Практики парного программирования и совместного владения кодом делают применение стандартов кодирования очень важной практикой.
Открытое рабочее пространство. Личные коммуникации между разработчиками и заказчиками являются самым важным в экстремальном программировании. Рабочее пространство должно иметь общие зоны, в которых можно легко устроить открытое общение между всеми участниками проекта.
40-часовая рабочая неделя. Экстремальное программирование рекомендует программистам не доводить себя до состояния усталости в течение дня. Это требование объясняется тем, что в состоянии усталости качество производимого разработчиком кода весьма низкое.
Игра в планирование. Техники для сбора требований в экстремальном программировании сильно отличаются от большинства традиционных методологий разработки программного обеспечения. Сначала требования заказчика записываются на естественном языке в виде так называемых «Историй пользователя» на карточках, что напоминает технику «вариантов использования». Эти карточки никогда не формализуются, между ними не выявляются зависимости и отношения. Разработчики программного обеспечения оценивают сложность выполнения каждого требования, а заказчик расставляет приоритеты по каждой такой карточке. Это происходит в процессе «игры в планирование» совместно между разработчиками и заказчиками. В ходе этой игры заказчик выбирает ту историю пользователя, содержание которой является наиболее важным и которую необходимо реализовать в ближайший месяц. После каждой итерации работы надо проектом заказчик проверяет и принимает результат работы команды разработчиков. Затем оставшиеся истории пользователя пересматриваются, возможно, изменятся их содержание или приоритет. Игра в планирование проводится снова для следующей итерации.
Методология экстремального программирования, наряду с другими гибкими методологиями, хорошо зарекомендовала себя в сообществе разработчиков программного обеспечения, и поэтому возникает необходимость исследовать вопрос о том, как применять практики экстремального программирования, такие как разработка через тестирование, рефакторинг, непрерывная интеграции и другие, в процессе обучения будущих инженеров-программистов.
Библиографический список
Амблер С. Гибкие технологии: экстремальное программирование и
унифицированный процесс разработки. СПб.: Питер, 2005. 412 с.: ил. (Библиотека программиста.)
Бек К. Экстремальное программирование. СПб.: Питер, 2002. 224 с.: ил.
Бек К. Экстремальное программирование: Разработка через тестирование. -СПб.: Питер, 2003. 224 с.: ил. (Библиотека программиста.)
Фаулер М. Рефакторинг: улучшение существующего кода: пер. с англ. СПб: Символ Плюс, 2003. 432 с., ил.
