Экстремальное программирование - молодая, но быстро развивающаяся методология разработки программного обеспечения. Она получила признание и широкое распространение благодаря ориентации на обычных людей, максимальному упрощению бюрократических процедур и обилию качественной литературы
Что же такое eXtreme Programming: набор отдельных правил и методик или полноценная методология? Давайте попробуем XP "на зуб", не отрывая глаз от страниц журнала.
С чего начинается экстремальное программирование? С понимания того, что типичное положение отечественного разработчика программного обеспечения обязывает максимально снижать стоимость разработки. А для этого необходимо интенсивно сотрудничать с заказчиком, понимать его интересы и, в конце концов, сделать именно то, чего он хочет: не больше и не меньше.
В основе экстремального программирования лежат не конкретные методики, как принято считать, а лишь четыре базовых принципа: общение, простота, обратная связь и храбрость. Именно с них необходимо начинать.
Экстремальное программирование предлагает готовое решение: делайте все максимально просто, держите заказчика при себе или сами держитесь при заказчике, позвольте ему активно следить за процессом разработки, приветствуйте изменения - и успех практически обеспечен.
В основе экстремального программирования лежат не конкретные методики, как принято считать, а лишь четыре базовых принципа: общение, простота, обратная связь и храбрость. Именно с них необходимо начинать.
В командах, работающих по методу XP, всегда приветствуется общение - самое быстрое средство обмена информацией и опытом. Это очень важно, когда требуется максимальная скорость разработки. Но общение, как и любое другое полезное начинание, требует постоянной поддержки. Именно поэтому кто-то из команды должен взять на себя ответственность следить за общением, стать так называемым дипломатом. Общение и необходимость объяснения своих действий другим членам команды вынуждает делать все максимально просто. Если не получается с первого раза, над упрощением работают еще и еще, пока не будет достигнута главная цель - максимальная понятность кода другим разработчикам.
Что бы мы ни делали - вдевали нитку в иголку или собирались на вечеринку - мы всегда стремимся достичь какой-то цели. Если мы замечаем, что отклоняемся от нее, то корректируем свои действия соответствующим образом. А теперь представьте себе, насколько тяжелей попасть ниткой в иголку с закрытыми глазами или красиво одеться без зеркала! А ведь при разработке программ часто так и происходит: мы делаем нечто, результат чего нам не виден. Поэтому в экстремальном программировании принято за правило видеть результат своих действий настолько быстро, насколько это возможно. Или, говоря техническим языком, обеспечить максимально быструю обратную связь.
Экстремальное программирование спрашивает нас: почему бы не воспитать в себе храбрость? Ведь она очень важна в работе. Разве можно без храбрости принять на себя ответственность за выполнение какой-то задачи, да еще в конкретные сроки? Разве можно без храбрости осознать, что ты уперся в тупик, сделать шаг назад и поискать обходной путь? И, наконец, что позволит разработчику признать свою ошибку в оценке задачи и вовремя предупредить об этом остальных вместо того, чтобы поставить их перед фактом уже тогда, когда все сроки истекут? Польза храбрости налицо, и каждый успех, даже в самой маленькой задачке, способен эту храбрость развить.
Таковы главные принципы. А теперь обратим внимание на целый арсенал методик экстремального программирования, позволяющих реализовать эти принципы.
Игра в планирование
Наш мир слишком изменчив и непредсказуем, чтобы полагаться на постоянство ситуации. То же происходит и при разработке программного обеспечения: о редкой системе можно сказать, что ее окончательный вид был заранее известен в деталях еще в самом начале разработки. Обычно у заказчика аппетит приходит во время еды: ему постоянно хочется что-то поменять, что-то улучшить, а что-то вообще выбросить из системы. Это и есть изменчивость требований, которую все так боятся. К счастью, человеку дано умение прогнозировать возможные варианты и, таким образом, держать ситуацию под контролем.
В экстремальном программировании планирование - неотъемлемая часть разработки и то, что планы могут поменяться, учитывается с самого начала. Той точкой опоры, методикой, которая позволяет прогнозировать ситуацию и безболезненно мириться с изменениями, является игра в планирование. В ходе такой игры можно быстро собрать известные требования к системе, оценить и запланировать их разработку в соответствии с приоритетностью.
Как и любая другая игра, планирование имеет своих участников и свою цель. Ключевой фигурой является, конечно же, заказчик. Именно он сообщает о необходимости той или иной функциональности. Программисты же дают ориентировочную оценку каждой функциональности. Прелесть игры в планирование заключается в единстве цели и солидарности разработчика и заказчика: в случае победы побеждают все, в случае поражения все проигрывают. Но при этом каждый участник идет к победе своей дорогой: заказчик выбирает наиболее важные задачи в соответствии с бюджетом, а программист оценивает задачи в соответствии со своими возможностями по их реализации.
Экстремальное программирование предполагает, что разработчики в состоянии сами решить, за какой промежуток времени они справятся со своими задачами и кто из них охотнее бы решил одну задачу, а кто другую.
В идеальной ситуации игра в планирование с привлечением заказчика и программиста должна проводиться каждые 3-6 недель, до начала следующей итерации разработки. Это позволяет довольно просто внести коррективы в соответствии с успехами и неудачами предыдущей итерации.
Тестирование до начала разработки
Тестирование, в его классическом понимании, - довольно скучная процедура. Обычно нанимают тестировщика, который периодически выполняет одни и те же действия и ждет того дня, когда его, наконец, переведут на другую должность или появится возможность поменять работу.
В экстремальном программировании роль тестирования интереснее: теперь вначале идет тест, а потом код. Как же тестировать то, чего еще нет? Ответ прост и банален: тестируйте свои мысли - чего следует ожидать от будущего куска программы или функциональности. Это позволит лучше понять, что требуется сделать программистам, и проверить работоспособность кода сразу, как только он будет написан.
Мне возразят: но ведь тест тоже может не работать. Что же, писать тест для теста? А потом тест для теста теста и так далее до бесконечности? Вовсе нет. Тест для теста заменит код. Как так? А вот смотрите: представьте себе, что нужно зафиксировать гайку посередине болта так, чтобы она не проворачивалась. Что для этого делают? Прикручивают вторую гайку вплотную к первой, так что каждая гайка не дает соседней проворачиваться. Так и в программировании: тест тестирует код, а код тестирует тест.
Опыт показывает, что такой подход не только не замедляет, но и ускоряет разработку. Ведь знание того, что нужно сделать, и требуемого объема работ позволят сэкономить время, отказавшись от реализации невостребованных в данный момент деталей.
Парное программирование
Опытные разработчики заметили, что периодический просмотр чужого кода положительно влияет на его качество. Мастера экстремального программирования развили этот подход: в ходе разработки код пересматривается постоянно посредством приема, именуемого парным программированием.
Парное программирование заключается в том, что два программиста работают за одним компьютером, пользуясь общими клавиатурой и мышкой. Такой незамысловатый подход не только повышает качество кода, но и обеспечивает более тесное общение, неявную передачу знаний, более эффективное использование рабочего времени, позволяет выявлять глобальные ошибки на ранних стадиях… И это еще далеко не все его преимущества. Исследования парного программирования показывают, что затраты на разработку не увеличиваются вдвое, а за счет экономии времени остаются приблизительно на том же уровне.
Постоянная переработка
Не секрет, что добавление каждой новой функциональности и разрастание кода усложняют разработку, выявление ошибок и внесение последующих изменений. Одной из уловок экстремального программирования является компенсация добавления функциональности усовершенствованием кода. Это и есть переработка кода, или рефакторинг.
Правила хорошего тона для большинства языков программирования, особенно объектно-ориентированных, давно сформулированы. Если ими грамотно руководствоваться при написании нового кода и учитывать все возможные изменения, то никакой переработки не потребуется. Но на такое мало кто способен. Код не всегда получается красивым с первого раза, отчего трудозатраты стремительно растут.
Переработка кода позволяет адекватно и немедленно реагировать на каждое изменение. Переработка кода - настолько мощный инструмент обеспечения качества программы, что может быть выделена в отдельную дисциплину. В частности, типовые случаи и подходы, применяемые при переработке кода, детально описаны в книге Мартина Фаулера "Рефакторинг".
Простота разработки
Экстремальное программирование учит нас делать все максимально просто - другими словами, не усложнять себе жизнь. В том числе и при разработке программного обеспечения. Простую программу легче поддерживать, в нее легче вносить изменения, она менее подвержена ошибкам.
Рассмотрим такой пример. Можете ли вы сходу сказать, что делает следующий код C++ и результат какой математической операции с переменной x отражен в переменной f?
int x = 5;
for (int i = 1, f = 1; i < x; i++, f *= i);
cout<
А если бы код выглядел так:
int x = 5;
int f = 1;
for (int i = 1; i < x; i++)
{
f *= i;
}
cout<
Наверное, со второго раза все узнали алгоритм подсчета факториала (3! = 1*2*3). Компьютер безболезненно воспримет оба варианта, но человека сложный код может поставить в тупик.
Коллективное владение кодом
Традиционно программный продукт поделен на сферы влияния между несколькими разработчиками. Каждый программист разрабатывает и отвечает за определенные участки программы.
В такой схеме каждый разработчик является специалистом узкого профиля. Он понятия не имеет, что творится в коде соседей. Если требуется внести изменения в "чужой" код, программист вынужден попросить об этом "владельца" соответствующей части программы.
Такая расстановка сил оправдана, если в команде царит абсолютное доверие и надежность каждого безупречна. Но представьте, что произойдет, если один из разработчиков уйдет в отпуск, заболеет или вовсе уволится? Насколько замедлит разработку такое выпадение звена из общей цепочки?
Вместо того чтобы надеяться на удачу, экстремальное программирование предлагает смотреть реальным трудностям в лицо. Для того чтобы компенсировать возможные "выпадающие звенья", используется принцип коллективного владения кодом. Каждым участком кода должны владеть как минимум два программиста, и любой член команды может внести изменения в любой кусок кода.
Работоспособность такого подхода поддерживается другими методиками, такими как модульное тестирование и простота разработки. Внести изменения в простой код несложно, а если от этого нарушится что-то написанное ранее, об этом сразу просигнализируют модульные тесты.
Продолжающаяся интеграция
Очень часто разработчики сталкиваются с проблемами поздней интеграции, когда новая функциональность оказывается несовместима с остальным проектом. Единственным эффективным средством решить такую проблему является продолжающаяся интеграция. Интегрировав работоспособный участок кода раньше, можно побороть или даже предотвратить несовместимость на ранней стадии проекта.
Несмотря на свою простоту, такая методика имеет свои правила использования, такие как успешность выполнения имеющихся модульных тестов для интегрируемой функциональности, наличие функциональных или приемочных тестов и, конечно же, возможность отката к предыдущему состоянию. Как правило, интеграция и разрешение сопутствующих трудностей выполняются на отдельном компьютере парой программистов. Это позволяет свести к минимуму риск нежелательных последствий интеграции.
Заказчик на рабочей площадке
Основной проблемой разработки программного обеспечения является недостаток знаний программистов в разрабатываемой предметной области. Экстремальное программирование нашло выход и из этой ситуации. Нет, это не стажировка разработчика на предприятии заказчика - он тогда не захочет программировать. Наоборот, это участие заказчика в процессе разработки.
Разве может программист, досконально не понимая суть вопроса и не будучи телепатом, угадать, чего хочет заказчик? Ответ очевиден. Самым простым способом преодолеть такое неудобство - а экстремальное программирование учит нас находить самые простые решения - будет задать заказчику прямой вопрос. Более строгие подходы требуют всеобъемлющего предварительного анализа разрабатываемой области. В определенных случаях это оправдано, хотя и дороже обходится. Реальный опыт ведения приземленных проектов показывает, что невозможно собрать все требования заранее. Более того, даже если предположить, что все требования на текущий момент собраны, все равно останется одно узкое место: программы, как и все в природе, не создаются мгновенно, а тем временем бизнес-процессы могут поменяться. Это следует учитывать.
Многие сомневаются в возможности привлечения заказчика к процессу разработки. Действительно, заказчики бывают разные. Если привлечь заказчика или его представителя не удается, иногда оказывается целесообразным временный наем специалиста в разрабатываемой области. Такой шаг сократит неясности в работе, повысит скорость разработки и приблизит проект к тому, что желает получить заказчик. Это может быть выгодно и с финансовой стороны: ведь оплата труда программиста порой значительно превышает оклад специалистов других отраслей.
Быстрый выпуск версий
Ни один аналитик, даже самый квалифицированный, не поймет потребности заказчика лучше, чем он сам… попользовавшись готовым продуктом некоторое время. Эта ценная особенность человеческой природы легла в основу новой методики, которая формулируется следующим образом: дайте заказчику определиться со своими потребностями раньше, выпустив версию быстрее.
Впрочем, у этого подхода есть определенные ограничения: во-первых, пользователи не всегда готовы к быстрым переменам, а во-вторых, выпускаемый продукт должен быть всецело протестирован. Если с первой проблемой справиться проблематично, то вторая успешно решается применением автоматизированных тестов, модульных или приемочных.
Сорокачасовая рабочая неделя
Человек, особенно если он программист, ради дела способен на многое: задержаться на работе, выйти на работу на выходные, отказаться от отпуска, несколько суток не спать, сидя за клавиатурой… В общем, чего только не сделаешь ради любимого занятия. Но экстремальное программирование категорически против такого самопожертвования и нарушения принятых норм трудового права.
Это продиктовано не только соображениями законности и гуманности, а - в первую очередь - необходимостью повышения эффективности работы и строгой организации. Ведь экстремальное программирование - коллективная игра, рассчитанная не на индивидуумов, а на всю группу целиком. А такая вещь, как, например, парное программирование, возможна лишь при синхронизации биоритмов ее участников. И она невозможна, если один человек будет приходить на работу к девяти, а второй к двенадцати или один решит, что ему лучше поработать в субботу и воскресенье, а другому это неудобно.
Но самое главное - человеку, чтобы сохранить здоровье и работоспособность, необходим полноценный отдых. Восьмичасовой рабочий день и пятидневная рабочая неделя установлены именно из соображений максимальной продуктивности. Во многих западных фирмах поздний уход с работы расценивается как неуспеваемость или неспособность правильно распорядиться своим рабочим временем. В большинстве случаев это так и есть. Да и с медицинской точки зрения, задержки на работе ведут к постоянной усталости, раздражительности и снижению мозговой деятельности. Разве это эффективно? А как в таком коллективе организовать постоянное открытое общение между разработчиками, и возможно ли будет парное программирование? Ответ отрицательный. Нормы есть нормы, и их стоит придерживаться.
Стандарты кодирования
Как ни странно, но эта давно известная методика не всегда применяется разработчиками программного обеспечения. Экстремальное программирование в качестве обязательного условия успешности работы над проектом выдвигает требование применения стандартов кодирования.
Это оправдано со многих позиций: единообразный код более понятен другим разработчикам, а споры о пробелах перед скобками уже вошли в легенды, да и задумываться при внесении изменений в чужой код относительно форматирования выражений не придется.
Метафора системы
Экстремальное программирование обеспечило нас простым, но эффективным инструментарием для освоения разрабатываемой системы. В частности, первое представление о системе может быть получено посредством метафоры, или сравнения с существующими аналогами.
Человеческое мышление построено на образах: каждое слово вызывает в памяти ассоциацию с характерным образом. Специалисты учли этот факт и выделили его в отдельную методику. Теперь для понимания системы используется сравнение наиболее похожего ранее известного продукта или предмета с разрабатываемым. Всегда легче запомнить мелкие отличия, чем строить в уме всю систему по кусочкам.
Заключение
Эти методики собраны воедино не случайно. Их непротиворечивая совокупность способна ввести процесс разработки в интеллектуальный резонанс, заметно повысив качество продукта и приблизив время его выпуска. Основная прелесть всего экстремального программирования - прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику того продукта, который он желает получить на момент выпуска; и конечно же общение и обучение разработчиков без отрыва от производства.