Библиотека Интернет Индустрии I2R.ru

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

Его цель – сделать процесс кодирования не зависящим от случайных событий, таких как вспышки "озарения" у программиста, урезать вследствие этого время разработки и избавится от бесконечной войны с ошибками, неизбежно появляющихся в момент сборки кусков кода, написанными по отдельности. Эта методика набирает всё больше и больше последователей и среди крупных компаний. Ford Motor, Chrysler and IBM среди тех, кто сделал эту идеологию основной для своих программистов. Джон Гиблин, первый вице-президент Ирландской компании Iona, был инициатором перехода на экстремальное программирование летом прошлого года. "Моей целью было сокращение времени, уходящего на разработку продукта. Из-за длительности цикла разработки наши продукты очень часто выходили либо уже устаревшими, либо не совсем соответствовавшими растущим требованиям заказчиков", - говорит Гиблин. - "Написание новой версии сервера приложений - основного нашего продукта – показало, что переход был сделан не зря. По крайней мере, теперь наши программы попадают на рынок гораздо быстрее".

Эта методика была разработана в 1996 году, когда Chrysler пригласил на работу специалиста по разработке программного обеспечения Кента Бека и поставил перед ним цель: спасти проект системы для расчета заработной платы работникам – Chrysler Comprehensive Compensation (С3). Главным звеном в его антикризисном плане стала "элегантность написания кода", что сразу позволило решить множество проблем, а в конце концов вылилось в целую концепцию разработки программных продуктов.

В последнее время всё больше компаний стали внедрять у себя экстремальное программирование. Большинство использует её как средство от хаотичности и неорганизованности процесса написания программного продукта, которые присутствуют на большинстве предприятий в течение двух последних десятилетий, а наибольшее свой расцвет получили во время Интернет-бума середины 90-х. В то время большинство богатых компаний знали только один способ написания программ – нанять как можно большее число высококвалифицированных программистов не зависимо от того, во сколько обойдется их привлечение и содержание. Дальше их рассаживали по офисам, в течение нескольких недель или месяцев они писали свои части кода. Затем происходила сборка кусков и обязательный долгий процесс выявления ошибок. Большая их часть, причём, была вызвана именно тем, что части программы писались независимо друг от друга.

Поэтому интерес компаний к экстремальному программированию может легко быть объяснен начавшимся в США экономическим кризисом. Многие сейчас вынуждены объявлять о снижении прибыли и, соответственно, искать пути повышения эффективности, снижения издержек и улучшения качества продукта, в том числе и путём уменьшения количества ошибок. "Экстрим" практически полностью соответствует этим целям, но не стоит думать, говорят апологеты этого метода, что он позволит быстро создавать абсолютно совершенные продукты, так как никогда ни одна наспех сделанная программа не может стать совершенной.

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

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

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

Но экстремальное программирование не всегда является панацеей. Как говорит его создатель, Кант Бек, это метод работает наилучшим образом в группах от 2 до 10 программистов, это оптимальное число людей, когда они могут свободно общаться друг с другом. Для экстремального программирования не подходят проекты, привлекающие программистов в других городах и странах и связывающихся с головной компанией через Интернет.

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

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

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

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