Преимущества экстремального программирования

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

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

В последние годы начали появляться новые методологии проектирования. Одной из них является метод «экстремального программирования» (Extreme Programming — XP). Сторонники экстремального программирования стремятся улучшить качество программ, повысить его эффективность и снизить стоимость. Обязательное тесное взаимодействие участников проекта и сжатость цикла разработки, характерные для XP, могут показаться приверженцам традиционного программирования несколько авантюрным подходом, ведущим к хаосу, но тем не менее такая методология позволяет более полно удовлетворить потребности заказчиков, а следовательно, принести дополнительный доход.

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

Успехи Open Source хорошо видны на примере ОС Linux, Web-сервера Apache и других программ, получивших самое широкое распространение.

Подходы Open Source и XP имеют ряд общих свойств, главными из которых являются непосредственное вовлечение заказчиков в проектировании программ, ускоренный цикл разработки и коллективное владение кодом. Этими концепциями обусловлено отличие XP и Open Source от традиционных методологий.

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

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

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