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

Первые 12 лет своей карьеры программист Марк Виндхольц (Mark Windholtz) провел за компьютером в одиночестве. Теперь, составляя код, он чувствует плечо друга – одного из приверженцев метода разработки ПО, называемого экстремальным программированием. «Работая в одиночку, легко сбиться с правильного пути, – говорит Виндхольц. – При „парном” же программировании этого не происходит – а если и происходит, то очень редко… Когда один теряет нить мысли, другой подхватывает ее».

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

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

Новая методология приобретает все больше и больше сторонников. Экстремальное программирование – по крайней мере отчасти – используют Ford Motor, Chrysler, IBM и другие компании. Джон Гиблин (John Giblin), старший вице-президент по инжинирингу в ирландской компании Iona Technologies, начал приобщаться к экстриму прошлым летом, чтобы сократить время выпуска продуктов. «Иногда из-за длительных циклов разработки к моменту готовности продукта предъявляемые к нему требования уже не вполне совпадают с заданными изначально», – говорит он. С тех пор как Iona использует экстрим для разработки своего серверного прикладного ПО, многое в этом плане изменилось. «Во всяком случае мы стали выпускать продукты гораздо быстрее», – говорит Гиблин.

Новая методология появилась в 1996 году, когда автогигант Chrysler обратился к разработчику ПО Кенту Беку (Kent Beck), чтобы тот спас проект, называемый Chrysler Comprehensive Compensation, или С3. Бек предложил формулу, в основе которой лежал набор правил, гарантирующий написание «элегантного кода». Сейчас система С3 ежемесячно расcчитывает зарплату более чем 86 тыс. рабочих Chrysler. Легко понять, почему другие компании обращаются к экстремальному программированию, избавляясь от бессистемного подхода к созданию ПО, который практиковался десятилетиями – особенно в период бума, царившего на фондовых рынках в 90-е годы, когда многие богатые технологические компании, невзирая на расходы, нанимали как можно больше ведущих программистов. Затворившись в офисах на недели или месяцы, эти программисты отбарабанивали код. Затем отдельные куски соединялись, и начинался долгий процесс отладки.

«Обычно последним этапом цикла разработки продукта бывает интеграция. Тут-то и обнаруживается, что не все компоненты как следует подходят друг другу, – говорит последователь метода экстремального программирования старший консультант компании Advanced Technologies Integration Кайл Ларсон (Kyle Larson). – При экстремальном программировании не возникает трудностей интеграции, так как она осуществляется в процессе всей работы».

Близким соратником Бека был ревностный сторонник экстрима Рон Джеффрис (Ron Jeffries), соавтор книги Extreme Programming Installed. «Вы нанимаете кучу программистов, говорите им, что вам нужно, но при этом отсутствует какая-либо организационная структура», – поясняет Джеффрис недостаток традиционного подхода к разработке ПО.

В условиях замедления темпов экономического роста к экстремальному программированию начнет прибегать все больше компаний, которые ищут новые способы повышения эффективности программ и устранения дефектов задолго до выхода окончательного продукта. «Предлагаемое решение должно быть совершенным», – говорит Дэвид Осборн (David Osborne), главный технолог консалтинговой фирмы по э-бизнесу, обслуживающей заказчиков из перечня Fortune 500. Экстрим обещает именно такие решения – предполагая, что совершенный продукт не может быть создан быстро, а продукт, созданный быстро, не может быть совершенным.

Зри в корень

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

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

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

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

Экстремальное – не всегда лучшее

Бек говорил, что его метод более всего подходит для групп из десяти или менее программистов. При такой численности коллектива создаются оптимальные условия для личного контакта и непосредственного устного обмена новостями. Предпочтительны также проекты, ограниченные небольшой географической областью: в этом случае проще организовать парное программирование. В крупных проектах, где часто требуется наличие обширной документации, личные контакты экстрима приходится по крайней мере дополнять документопотоком. Но несмотря на эти ограничения, защитники экстрима не нарадуются на него. «Я стал работать лучше – и успеваю больше», – говорит руководитель технического отдела чикагской компании ThoughtWorks Джек Боллес (Jack Bolles).

За прошедшие годы программисты создали и другие методы организации разработки ПО. Например, метод водопада заключается в том, что компании заранее определяют все функции, которые должны быть включены в программу, раздают задания разным людям, а в конце выполняют процесс интеграции. «В этом случае предполагается, что заказчик заранее знает, что ему нужно, но так никогда не бывает. А если мнение вашего заказчика изменится, это становится большой проблемой», – говорит Ларсон.

Экстремальное программирование, напротив, поощряет корректировки и дополнения к продуктам в процессе разработки. К тому же в нем используется стратегия постоянного сотрудничества и личных контактов. Залогом успеха служит человеческое общение – даже в холодном, расчетливом мире компьютерного программирования. «Иногда чувствуешь себя очень уставшим и одиноким, – говорит экстремальный программист Стив Фриман (Steve Freeman). – Бывает, не знаешь, что делать дальше. Работать в паре гораздо приятнее. По крайней мере рядом есть кто-то еще, кто понимает проблему».

Сесиль Бернес

Январь 9, 2008 — Рубрика: Мнения специалистов
Метки: , , , ,