Экстрема́льное программи́рование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Список используемой литературы:
Возможно, это прозвучит странно, но около 75% програмного обеспечения вообще не выходит в люди. С другой стороны, существует множество компаний, которые производят софт в огромном количестве. Все это и многое другое обязывает программистов снижать стоимость разработки. А для этого нужно понимать интересы заказчика, постоянно сотрудничать с ним, чтобы в итоге создать именно то, что ему необходимо.
Методология разработки програмного обеспечения eXtreme Programming (изобретатель - Kent Beck) получает все большее признание благодаря максимальному упрощению процессов проектирования и непосредственной разработки програмных продуктов в среде с быстро изменяющимися требованиями.
Существует всего лишь 5 ценностей экстремального программирования: простота, общение, обратная связь, смелость и уважение ("уважение" добавилось в последней редакции XP). На реализию этих основных ценностей и направлены 12 практических методик XP. Рассмотрим их в небольшом приближении. Кроме изветных многим истин, добавлю свои комментарии по поводу практик, основываясь на своем практическом опыте.
Процесс планирования (planning game). В XP планирование - это основная часть разработки. То, что планы могут внезапно поменяться, учитывается еще в самом начале. Аппетит заказчика приходит во время еды и нужно всегда держать ситуацию под контролем. Общение с заказчиком должно происходить как можно чаще. Это позволит точнее оценить сроки выполнения задач и внести необходимые коррективы в случае необходимости.
Быстрый выпуск версий (small releases). Как бы красиво не был описан продукт, все прелести его использования можно понять только работая с ним. Методика быстрого выпуска версий позволяет понять, чего же хочет заказчик, обеспечивая ранний выпуск рабочих версий продукта.
Комментарий: Как показывает практика, первую раннюю версию можно сделать за 2-8 недель, не зависимо от ожидаемой сложности продукта. Желательно, чтобы первую версию продукта (хотя бы первые несколько итераций) делало 2 человека за одним компьютером. В этом случае очень быстро вырисовывается дизайн системы. Далее можно привлекать еще людей, перераспределив пары.
Метафора (metaphor). Человеку намного легче запомнить отличия между двумя схожими предметами, чем знать строение предмета полностью. Методика метафора предлагает сравнивать систему (или один из ее модулей) с ее аналогами для удобства общения внутри команды и более глубокого понимания системы в целом.
Комментарий: Достаточно сложная практика, хотя на первый вгляд и кажется простой. Придумать метафоры для основных модулей системы - это не просто, но очень полезно. Многие программисты относят "метафору системы" к управленческим практикам, но мне кажется, что больше нужна она все-таки разработчикам. Правильный выбор метафор в конечном итоге поможет программистам придумать удачные названия классам и методам, что всегда положительно влияет на дизайн системы в целом.
Простота реализации (simple design). XP предлагает делать код программы простым. Зачем усложнять себе жизнь, если простую программу легче понимать и поддерживать и она менее подвержена ошибкам.
Опережающее тестирование (test-driven development). Экстремальное программирование рекомендует проверять существующий код как можно чаще. Именно поэтому и практикуется данная методика. Тесты пишутся еще до того, как будет написан кусок кода. Это позволяет лучше понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.
Комментарий: У такого подхода есть масса плюсов.
Во-первых, писать тесты перед написанием кода - один из лучших способов гарантировать наличие этих самых тестов.
Во-вторых, исключается нежелание тестировать некоторые "очевидные" ветки выполнения программы, хотя бы потому, что кода еще нет:). Ну и потом, при парном программировании тесты дейтвительно будут лаконичными и качественными.
В третьих, тесты усиливают уверенность программистов в себе, когда у них возникает желание произвести рефакторинг.
Рефакторинг (design improvement). Добавление новой функциональности и увеличение объема кода усложняет разработку и поиск ошибок. Решением этой проблемы является постоянная переработка (refactoring) кода. Рефакторинг - очень мощная и полезная вещь и заслуживает не то что отдельной статьи, а целых книг.
Комментарий: Не забывайте о ценности "смелость" и не бойтесь поламать систему во время рефакторинга. Тесты покажут, что сломалось и вы быстро исправите ошибки. Даже если тесты не покрывали некоторые аспекты, и вы не заметите какие-то потенциальные проблемы - ничего страшного, все всегда можно исправить. Главное, что дизайн системы стал проще и понятнее, а сложная система - это источник куда более ужасных ошибок, чем ошибки возникшие в результате рефакторинга.
Парное программирование (pair programming). Периодический просмотр чужого кода положительно влияет на его качество. Этот принцип лежит в основе парного программирования. Заключается оно в том, что два программиста одновременно работают за одним компьютером. Как ни странно, затраты на разработку не увеличиваются в два раза, а остаются приблизительно на том же уровне. С другой стороны при парном программировании повышается качество кода, осуществляется неявная и явная передача знаний, а также проиходит постоянное общение между разработчиками.
Совместное владение кодом (collective code ownership). Чаще всего при разработке програмных продуктов за определенную часть кода отвечает один человек. Отпуск, увольнение или же болезнь (прости, Господи) одного из программистов может сильно затормозить разработку продукта. Именно поэтому в XP за один кусок кода отвечает не менее двух человек и любой программист может внести изменения в любую часть програмного кода.
Продолжающаяся интеграция (continuous integration). Команды XP-программистов создают новые билды продукта несколько раз в день. Это позволяет всем программистам быть в курсе происходящего и предотвратить проблемы интеграции с другими продуктами и частями кода.
Комментарий: В наше время эта практика у молодых специалистов вызывает улыбку или даже непонимание, ведь есть svn, perforce, cvs и еще много чего. Это раньше двое дядек садилось возле главного компьютера и вручную мержились с основной веткой проекта.
Тем не менее эта практика актуальна до сих пор. Совместное владение кодом никто не отменял: не хочешь тратить время на огромный и сложный merge - потратить время на несколько маленьких мержиков:).
40-часовая неделя (forty hour week). Ради дела люди спопобны на многое, но экстремальное программирование категорически против самопожертвования разработчиков. Человек должен отдыхать, именно тогда он достигнет максимальной производительности в рабочее время.
аверное, каждый проектировщик или аналитик хотя бы раз в жизни сталкивался с заказчиком, стремящимся получить свой проект как можно дешевле и вдобавок в максимально сжатые сроки. Но если стоимость проекта - вполне реальный предмет торга, то вести переговоры о корректировке сроков сдачи проекта куда сложнее. Нетерпеливых клиентов сегодня становится все больше и больше, что объясняется и состоянием современного динамичного рынка, и падающим уровнем доверия между исполнителями и заказчиками, и поведением инвесторов, у которых аппетит приходит во время еды (при наличии более или менее работающей версии продукта деньги на дальнейшую разработку дают намного охотнее), и т.д. В связи с этим классические методологии разработки (при которых долгий цикл собственно проектирования и сбора информации, когда клиент вкладывает значительные средства, а реального результата довольно долго не получает) вступают в весьма жесткое противоречие с интересами нетерпеливого заказчика. Все это и дало толчок развитию альтернативных методологий проектирования в двух основных направлениях: повышение доверия заказчика путем предоставления реальных доказательств успешно развивающегося процесса разработки и резкое сокращение сроков разработки продукта. Группа таких методологий получила название «активное программирование».
ак правило, конечные пользователи и представители руководства компании-заказчика полагают, что процесс проектирования не увенчался успехом, если отсутствуют реальные готовые компоненты. Зачастую заказчик настаивает на досрочном проведении этапа реализации проекта, чтобы как можно быстрее получить конкретный результат и продемонстрировать его. В таком случае существует большой соблазн выбрать ускоренную разработку приложений (УРП) или совместную разработку приложений (СРП). Подобные методы предусматривают разработку рабочего прототипа с последующей демонстрацией его пользователям, которые отмечают, что им нравится, а что нет. После этого проектировщик дорабатывает прототип с учетом сделанных замечаний, а затем снова демонстрирует то, что получилось. Процесс повторяется до тех пор, пока пользователи не будут удовлетворены тем, что они видят, а прототип не станет рабочим приложением. Обычно устанавливаются лимит времени и количество итераций, ибо в противном случае пользователи будут бесконечно требовать новых совершенствований прототипа. Теоретически это позволяет получить именно ту систему, которая необходима пользователям.
Итак, здесь мы наблюдаем итеративную модель разработки с очень короткими циклами спирали в обоих случаях. И в том и в другом методе сокращено время, затрачиваемое на начальные этапы проектирования: стратегию (либо опускается вообще, либо сливается с анализом), анализ (в большинстве случаев ограничивается первичной выборкой информации и анализом форм - как правило, отчетов, по которым и пытаются восстановить структуру функций системы), проектирование (нацелено на как можно более быстрое получение первичного прототипа). Результатом разработки является прототип, который затем подлежит промышленной реализации. В данном случае тестирование производится при активном участии заказчика, либо заказчик становится тестером (в лучшем случае бета-тестером).
На практике подобный подход к разработке приложений сопряжен с проблемами, перечисленными ниже:
Все внимание сконцентрировано на экранных формах, а все, что касается правил обработки данных и системных функций, остается за кадром. Существует искушение начать работу с отчетов, в то время как отчет является не стартовым, а производным продуктом информационной системы.
Пользователи полагают, что если вариант прототипа согласован, то модуль готов. На самом деле это может быть всего лишь картинка с набором «заглушек» для вызовов системных функций и взаимодействия с другими модулями.
Модули проектируются изолированно друг от друга. Следствием этого являются противоречия модулей, дублирование функций и данных, что может быть выявлено только при тестировании комплекса модулей.
Функциональные возможности наращиваются параллельно в нескольких направлениях, поэтому структура хранилища данных должна контролироваться. При УРП схема базы данных напоминает свалку, где таблицы лепятся на скорую руку, а результат - набор противоречивых и дублирующихся данных.
Документация при использовании метода УРП, как правило, отсутствует по двум причинам: не хватает времени и создается иллюзия, что пользователь способен без документов поняв суть происходящего. Когда же приложение начинает работать не так, как ожидал пользователь, возникают проблемы.
Способы обработки исключительных ситуаций оказываются различными для разных модулей.
Возникает проблема интеграции модулей: целостной системы, как правило, не получается, потому что изначально она проектировалась как набор компонентов, которые впоследствии были наспех связаны между собой.
Контроль качества продукта вступает в жесткое противоречие со сроками разработки проекта, в результате чего стадии тестирования и внедрения очередной версии продукта практически сливаются и переносятся непосредственно на полигон заказчика. Понятно, что в этом случае происходит с заказчиком, который крайне недоволен качеством продукта; иными словами, сор из избы выносится абсолютно не вовремя.
Возникает вопрос: можно ли решить подобные проблемы и каким образом? Ведь так хочется получить проект максимально быстро! В какой-то мере экстремальное программирование (eXtreme Programming, XP) можно считать эволюцией, а возможно, и революцией в сфере более молодых методологий активного программирования. Подойдет ли данная методология конкретно для вашего коллектива разработчиков - решать вам и только вам, поскольку, например, далеко не все приходят в восторг от экстремальных видов спорта.
Отцом-идеологом экстремального программирования считают Кента Бека (Kent Beck). XP является достаточно молодой методологией, оценки которой весьма противоречивы - от восторженных до резко негативных. Основными принципами являются:
Простота решений (simplicity).
Интенсивная разработка малыми группами (не больше 10 человек), активное общение в группе и между группами (communication).
Обратная связь с клиентом (feedback), который фактически вовлечен в процесс разработки.
Достаточная степень смелости (courage) и желание идти на риск.
Первый фактор ускорения разработки - итеративность: разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. XP - это итеративный процесс разработки, который сам по себе не является революционным. Итерации как таковые предлагается делать короткими, рекомендуемая длительность - 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории (user story). Пользовательские истории в данном случае являются начальной информацией, на основании которой создается модуль. Пользовательские истории отличаются от прецедентов (use case): пользовательская история коротка - 1-2 абзаца, тогда как прецеденты обычно пишут достаточно подробными, с основным и альтернативными потоками - таким образом, получается примерно страница плюс схема (наиболее распространенная формализация в настоящее время предложена в UML); истории пользователей пишутся самими пользователями (которые в XP являются частью команды) в отличие от прецедентов, которые обычно пишет системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком (активное общение и непрерывная поддержка обратной связи). В данном случае extreme - это степень привлечения заказчика к программистской кухне, что обусловлено стремлением сжать сроки разработки за счет коммуникации и обратной связи.
Второй фактор ускорения разработки продукта - наличие малых групп и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте). Все это нацелено на достижение высокого уровня общения в группе, а также на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование преследует цель стабилизации проекта, так как при данной методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода (что в классических методиках реализуется в технической документации). Немаловажно и то, как именно распределены группы в рабочем пространстве - в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем; как правило, рабочее пространство строится на основе круга.
Третий фактор ускорения разработки процесса - принятие первого наипростейшего рабочего решения. В данном случае экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.
Обычно XP характеризуют набором из 12 действий (практик), которые необходимо выполнять для достижения хорошего результата. Практики XP не определяют сам процесс XP, но XP определяет эти практики - то есть выполнение практик не гарантирует результата. Ни одна из практик не является принципиально новой, но в XP они собраны вместе.
Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.
Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).
Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры - крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.
Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.
Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Определение наиболее важных объектов стандартизации в XP субъективно.
Рефакторинг (refactoring). Рефакторинг - это оптимизация существующего кода в сторону упрощения, что предусматривает постоянную работу по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг надо отложить.
Парное программирование (pair programming) - одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.
40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) - это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение - одно из основных правил.
Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.
Частая смена версий (small releases). Минимальная итерация - один день, максимальная - месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.
Непрерывная интеграция (continuous integration). Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это жесткое и однозначное - если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.
Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP - одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test - тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.
Итак, XP крайне пренебрежительно относится ко всем артефактам процесса разработки, кроме исходного кода. Процесс XP является в высшей степени неформальным, но требует высокого уровня самодисциплины. Если это правило не выполняется, то XP мгновенно превращается в хаотичный и неконтролируемый процесс. XP не требует от программистов написания множества отчетов и построения массы моделей. В XP каждый программист считается квалифицированным работником, который профессионально и с большой ответственностью относится к своим обязанностям. Если в команде этого нет, то внедрять XP абсолютно бессмысленно - лучше для начала заняться перестройкой команды. Риск разработки снижается только в команде, которой XP подходит идеально, во всех остальных случаях XP - это процесс разработки с наиболее высокой степенью риска, поскольку другие методы снижения коммерческих рисков, кроме банального человеческого фактора, в XP просто отсутствуют.
Существующие риски применения методологии
Следует выделить риски XP, способные завалить проект, если не учитывать и не предотвращать их.
Этап планирования (planning game). Программисты реализуют только те функции, которые необходимы для возможностей, выбранных на данной итерации заказчиком. В результате такого решения за кадром остается развитие системы, вследствие чего при разработке возникает необходимость строить «заглушки» и переписывать код.
Постоянное участие заказчика (on-site customer). Представитель заказчика в период работы над системой находится в команде разработчиков, причем требования к квалификации этого человека или команды весьма высоки. Если заказчик не согласился предоставить персонал уровня экспертов, то проект попадает в группу наиболее высокого риска.
Метафора (metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты. Если не ведется журнал данного процесса и структура наименований не стандартизована, то такой процесс может оказаться бесконечно итерационным.
Простая архитектура (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз». Данный принцип вступает в противоречие с быстротой написания кода. Без наличия высокой самодисциплины и жестких стандартов кода система немедленно попадает в группу риска.
Частая смена версий (small releases). Систему запускают в эксплуатацию уже через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых версий может варьироваться от ежедневной до ежемесячной. Протестировать за такой срок более-менее сложный компонент невозможно; заказчик фактически выступает в роли бета-тестера. Системы, к которым предъявляется требование непрерывной надежной работы (так называемое требование 24Ѕ7), входят в группу риска.
Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов. Экстремальное программирование исходит из того, что переделать часть системы всегда можно, причем без особых затрат. Однако практика довольно часто свидетельствует об обратном.
Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются. В данном случае не всегда понятно, кто именно будет исправлять ошибки, причем не только локальные, но и наведенные неправильным кодом. Проведение комплексных тестов на данном этапе не предполагается; кроме того, изменения сохраняются даже в том случае, когда ошибка обнаружена.
Программирование в паре (pair programming). Весь код проекта пишут группы по два человека, использующих одно рабочее место. Человеческий фактор в данном случае играет определяющую роль: пара или работает или нет, третьего не дано.
40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, служат признаком серьезных проблем, которые требуют безотлагательного решения. Как показывает практика применения экстремального программирования (несмотря на целый ряд положительных примеров, приводимых сторонниками данного метода), сверхурочная работа при таком подходе - это правило, а не исключение, и борьба с проблемами в данном случае - явление постоянное. Усиливается она в период замены текущей сырой версии продукта очередной - менее сырой. Если заказчик не получает постоянных доказательств улучшения системы, значит, у вас возникли серьезные проблемы.
Коллективное владение (collective ownership). Каждый программист имеет возможность при необходимости в любое время усовершенствовать любую часть кода в системе. Без стандарта контроля исходного кода процесс разработки приобретает абсолютно неконтролируемый характер.
Открытое рабочее пространство (open workspace). Команда разработчиков располагается в большом помещении, окруженном комнатами меньшей площади. В центре рабочего пространства устанавливаются компьютеры, на которых работают пары программистов (причем в соответствии с вышеизложенными принципами, все это должно располагаться на территории заказчика, поскольку он весьма активно привлекается к процессу разработки). При наличии территориально распределенной группы разработчиков и заказчиков проект требует стандартизации протокола взаимодействия (быстро, надежно, безотказно) или попадает в группу риска.
Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Для этапов итерации заказчики пишут функциональные тесты (functional tests), от которых также требуется правильная работа. Однако на практике это не всегда достижимо. Чтобы принять верное решение, необходимо понять, во что обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на его устранение. Тесты, написанные самими программистами (особенно в условиях сверхурочных работ), не являются полнофункциональными и уж тем более не учитывают особенностей многопользовательской работы. На более продвинутые тесты у разработчиков обычно не хватает времени. Решается данная проблема путем привлечения на определенный срок контакторов, что связано с большой ролью человеческого фактора: поскольку техническая документация изначально отсутствует, то информация передается посредством общения программистов. Хотя, конечно, можно построить систему разработки таким образом, что от начала до конца всем будут заниматься одни и те же люди. К сказанному необходимо добавить, что тестирование системы вовсе не исчерпывается тестами компонентов (units); не менее важны тесты взаимодействия между ними, это же относится и к тестам надежности работы. И тем не менее метод экстремального программирования не предусматривает создания тестов данного класса. Это объясняется тем, что сами подобные тесты могут представлять достаточно сложный код (особенно это касается тестов - имитаторов реальной работы системы). В данной технологии также никак не учитывается еще один важный класс тестов - тесты поведения системы при росте объемов обрабатываемой информации. При высокой частоте изменения версий выполнить такой тест технологически невозможно, поскольку его проведение требует стабильного и неизменного кода проекта, например в течение недели. В таком случае придется или приостанавливать разработку компонентов, или создавать на время проведения теста параллельную версию проекта, которая будет сохраняться неизменной, тогда как другая при этом будет изменяться. Затем нужно будет выполнить процесс слияния кода. Но в этом случае тест придется создавать заново, так как методы экстремального программирования просто не предусматривают разработку средств, позволяющих прогнозировать поведение системы при тех или иных изменениях. Решать данные проблемы в XP предлагается посредством все того же человеческого фактора и самодисциплины.
Не более чем правила (just rules). Члены коллектива, работающего по технологии экстремального программирования, обязуются выполнять изложенные правила. Однако это не более чем правила, и команда может в любой момент изменить их, если ее члены достигнут принципиального соглашения по поводу внесенных изменений. Данный принцип серьезно зависит от человеческого фактора; нарушение дисциплины разработки влечет за собой срывы сроков и в результате ведет к краху проекта.
В итоге мы получаем метод, потенциально обладающий высокой адаптацией к серьезно и часто изменяющимся требованиям к проекту, но в то же время не свободный от ряда принципиальных недостатков и в очень высокой степени зависимый от человеческого фактора.
Таким образом, результат применения метода экстремального программирования может получиться либо экстремально хорошим, либо экстремально плохим.
В последнее время среди разработчиков программного обеспечения стала
популярной технология, называемая «экстремальное программирование» или XP. Об
этом пишется масса статей и книг, которые дают понятие о теоретических основах
этой методологии. Мне бы хотелось рассказать, как это выглядит на практике, и
какие преимущества и недостатки
Прежде всего, что такое XP? В Интернете можно найти массу определений и описаний
этого термина. В принципе, каждое из них более-менее адекватно отражает суть
явления, но многообразие определений может запутать разработчика. Поэтому нужно
понимать, что XP это набор методик, выработанных для того, что бы подчинить
процесс разработки программного обеспечения четырем базовым принципам. А именно:
Обычно, в материалах по XP эти методики конкретизируются. Вот наиболее
типичный их перечень:
Я прокомментирую лишь некоторые методики, так как смысл большинства из них
вполне понятен из названия и подробно описано в литературе. Некоторые из этих
методик кажутся вполне логичными, некоторые, напротив, вызывают недоумение.
Игра в планирование Идея этой методики достаточно проста. Разработчики вместе с
заказчиками собираются вместе и проигрывают некоторые возможные ситуации (в
идеале все), которые могут возникнуть при решении задачи в жизни. Такие собрания
желательно устраивать перед началом разработки каждой подсистемы, то есть делать
это регулярно на протяжении всего процесса разработки. Это позволяет не
заниматься разработкой по жесткому плану, а своевременно адаптироваться к
изменениям в предметной области.
Тестирование до начала разработки. Предполагается, что перед началом разработки
какого-либо фрагмента программы пишется тест для него. Это дает ряд преимуществ.
Во-первых, бывает так, что один изменения в одном фрагменте кода влекут за собой
ошибки в другом. Такой подход к тестированию позволяет моментально выявлять
такие ситуации. Во-вторых, заказчику удобнее наглядно видеть, что тест работает,
чем читать большие объемы документации. Именно поэтому результат работы теста
нужно визуализировать.
Метафора системы. Разрабатываемые продукты или фрагменты кода сравниваются, с
какими-либо аналогичными продуктами или явлениями. Строятся метафоры. Это
упрощает понимание задачи, а, соответственно, ускоряет разработку.
Но так же нужно понимать, что в том случае, если в силу каких-либо причин
какая-либо из этих методик начинает идти вразрез с основными принципами XP, а
такие ситуации вполне возможны, то от нее следует отказаться.
Откровенно говоря, не смотря на то, что перед началом описываемых событий я
имел общее представление об экстремально программировании, но в процессе
разработки приложения, о котором я хочу вам рассказать, осознанно придерживаться
методов XP я не пытался. Тем не менее, на мой взгляд, это является типичным
примером XP. В любом случае, позитивный результат был достигнут.
Теперь давайте посмотрим, как подходы ХР могут быть использованы на практике в
наших условиях. Одной из моих на работе задач является автоматизация учебного
процесса. Собственно говоря, я на протяжении достаточно большого отрезка времени
занимаюсь написанием приложения, осуществляющего (по крайней мере по замыслу
автора:)) комплексное решение этой проблемы. Бюджет у проекта мизерный, а объем
работ – приличный. Еще одним, чуть ли не решающим фактором было постоянное
видоизменение предметной области. Регулярно меняются формы отчетной
документации, и методика их получения. Сложилась ситуация, когда проект перестал
успевать за требованиями пользователя. И однажды наступил момент, когда в силу
объективных и субъективных причин, разработку можно было смело хоронить. Однако
неожиданно передо мной была поставлена конкретная задача определения
загруженности аудиторного фонда на семестр. К этому моменту из трех участников
проекта остался я один, а данная подсистема не была реализована и реализация ее
даже не стояла в ближайших планах развития проекта. О таких мелочах как
грамотная постановка задачи, подсчет трудоемкости работ, выделении
дополнительных ресурсов никто даже и не задумался. На выполнение задачи было
отведено две недели. При этом мои аргументы, касающиеся невозможности выполнения
данной задачи не рассматривались в принципе. Первым моим решением было подыскать
себе другого работодателя, так как за две недели я был должен написать не только
модуль анализа загруженности аудиторного фонда, но и систему ввода расписания
занятий, контроля накладок и многое другое. Автономно, данная задача не решается
в принципе — нужны исходные данные. И не просто исходные данные, а корректные
исходные данные, откуда и вытекают все вышеперечисленные задачи. Тем не менее,
не знаю почему, но я взялся за решение этой задачи.
Естественно, что говорить о разработке классическими методами в данном случае
неуместно. Вот здесь-то и пригодились подходы ХР. Общее представление о задаче я
уже имел, однако имелось множество нюансов, которые потенциально могли
значительно увеличить объем работ. Начал работу я с того, что набрал номер
учебного отдела и стал засыпать снявшего трубку массой вопросов, ответы на
которые я не мог найти самостоятельно или в которых я не был уверен.
.
Я запустил Rational Rose и приступил к составлению модели. К концу рабочего дня
я набросал модель, показавшуюся мне более-менее адекватной. После работы я
предпринял еще один шаг, отвечающий идеологии ХР. Я вытащил своего приятеля,
работающего в учебном отделе попить пива. В процессе этого, важного во всех
отношениях мероприятия, я изложил ему свое виденье программы, ее интерфейса и
логики работы. Он, в свою очередь, принимался рассказывать о необходимости
решения некоторых локальных подзадач. К вечеру я уже более четко уяснил, что же
все-таки нужно сделать в рамках данного проекта (я уже не сомневался, что задачу
следует рассматривать как отдельный проект). Тем не менее, не был решен еще один
не маловажный вопрос – выбор средств разработки. Когда происходили описываемые
события, я начинал активно изучать MDA технологию. Вкратце, суть ее такова:
фрагменты кода приложения и структуры данных генерируются автоматически, исходя
из UML модели, что позволяет существенно сократить время разработки. В рамках
данной статьи я не буду детально описывать принципы работы MDA, но хочу
акцентировать ваше внимание на том, что использование этой технологии полностью
отвечает «духу XP». Связано это с тем, что одним из условий, при котором
методики XP будут успешно работать, это снижение стоимости изменений, вносимых в
приложение на поздних стадиях разработки. Среди факторов, способствующих
достижению этого, не маловажным является использование различных новых
технологий программирования. Замечу, что именно простота рефакторинга MDA
приложений является одним из основных преимуществ этой технологии. Вообще, на
сегодня существует достаточно много реализаций MDA, я остановил свой выбор на
Bold for Delphi.
Но в моей ситуации было несколько «скользких моментов». Во-первых, сознавая, что
MDA предоставляет определенные преимущества, я все же не достаточно уверенно,
владел этой технологией и, практически, не имел опыта написания MDA–приложений.
Во-вторых, я понимал, что некоторые фрагменты кода будет проблематично
реализовать стандартными средствами MDA, и предстоит много «ручного
кодирования», которое в данном случае будет иметь определенную специфику.
Альтернативным вариантом было написание «обычного» Delphi приложения. Я запустил
ICQ и написал сообщение своему знакомому – адепту Bold. После того, как я
вкратце изложил ему суть проблемы, я спросил, как бы он на моем месте поступил.
Он ответил примерно следующим образом: «Либо погружаться с головой в Bold, либо
ты никогда не освоишь его. Сделать серьезный проект – лучший способ изучить
технологию». Собственно, другого ответа я и не ожидал.
С утра я взял существующую модель и начал строить приложение. Именно, строить. К
кодированию я не приступал, а просто набросал пользовательский интерфейс, многие
элементы которого практически сразу заработали. На перекур я старался выходить в
компании сотрудников учебного отдела, это позволяло мне затащить очередную
«жертву» к экрану своего монитора и (не без некоторой доли гордости) показывал
промежуточные результаты. Таким образом, реализовывался принцип обратной связи.
Вы можете справедливо заметить: «А как же парное программирование?». Да,
действительно, в качестве программиста в проекте участвовал я один. Но тут я
упомяну еще об одном счастливом стечении обстоятельств. В тот период времени,
когда происходили описываемые события, я, совместно с группой разработчиков —
энтузиастов развивал Интернет-проект, посвященный, именно MDA. И вот, когда я
подошел к самому сложному месту в своей разработке, этот проект принес
совершенно неожиданные результаты.
В течение нескольких дней я писал код процедуры, реализующей отображение занятий
на экране. Стандартные элементы управления не позволяли вывести на экран все
данные, в той форме, в которой они обычно представляются. Мне же хотелось, что
бы конечный пользователь хотя бы приблизительно понимал, что же делает программа
и как с ней работать. Я написал свой компонент, на основе обычного TStringGrid.
Я не был уверен в том, что это было хорошее решение, но код работал. В форуме
нашего проекта я изложил свое решение, ожидая получить какую-то оценку в течение
достаточно долгого промежутка времени. Однако буквально через 15-20 минут пришел
первый ответ. Предлагался альтернативный вариант решения, а еще через 10 минут
пришел тестовый пример, да не один, а сразу два, от двух авторов. Если
задуматься над тем, почему разработчики, с таким энтузиазмом принялись решать
чужую задачу, то можно прийти к простому выводу. Во-первых, им просто было
интересно найти некоторое универсальное решение, которое затем можно
использовать в своих проектах. А во-вторых, им был интересен сам процесс
общения. Надо отметить, что с таким же энтузиазмом решались и другие задачи
различного уровня сложности. Конечно, это не является парным программированием в
обычном понимании. Скорее это некий суррогат, но, тем не менее, в этом есть и
свои плюсы. Скажем, все высказываемые мысли, и идеи автоматически
документировались, и к ним можно было обратиться в любой момент.
На тестах я хотел бы остановиться отдельно. Как рекомендует в своей книге
«Экстремальное программирование» Кент Бек, тесты должны писаться заранее. Более
того, у автора это выглядит примерно так. Имеется специальная программа,
написанная самим разработчиком, при нажатии на одну из кнопок которой
запускаются все тесты, а в итоге на экране появляется зеленая «лампочка» в
случае позитивного результата и красная в противном случае. Меня такое описание
несколько обескуражило. Согласитесь, сложно себе представить, каким образом
можно написать программу, имитирующую действия пользователя, абсолютно во всех
ситуациях.
Как я уже говорил, я не старался строго придерживаться методик экстремального
программирования. А в прочитанных мною книгах недвусмысленно утверждалось, что
написание теста – один из наиболее важных моментов в XP, и без этого остальные
методики сработать не должны. Почему же в итоге я достиг положительного
результата? Все оказалось достаточно просто. Ответить на этот вопрос мне помог
именно этот пример с зелеными и красными лампочками. Дело в том, что в Bold
имеется возможность показать, соответствует – ли данный объект модели. И
делается это как раз с помощью подобных «лампочек». Буквально две строки,
которые я почти сразу вставил в код приложения, позволяли мне увидеть, в каком
месте происходит несоответствие (если таковое имеется). Именно это и заменило
мне тестирование. Возможно, что такой подход и не совсем соответствовал
оригинальной идее «тестирования до начала разработки», но это сработало.
Уже через неделю я обладал практически готовым приложением. В течение второй
недели, я сделал еще две версии, в которых серьезно расширил функциональность, а
так же осуществил импорт большинства необходимых для работы данных из других
работающих систем. Задача была решена, и во многом за счет использования
методик XP. Смысл всего вышеизложенного я вижу лишь в том, что этот пример на
практике доказал работоспособность экстремального программирования.
В заключение, я хочу сделать еще одно замечание. Экстремальное программирование,
на мой взгляд, не является панацеей. И применять его методики можно далеко не
для любого проекта. В принципе, рассмотренный проект, по некоторым признакам
входил как раз в ту категорию проектов, где использовать XP не рекомендуется.
Однако, при более гибком подходе использование методик экстремального
программирования может принести весьма поразительные результаты. При прочтении
книги зарубежных авторов посвященных данной теме, у отечественного читателя
может сложиться мнение, что приемы XP в принципе не могут быть использованы в
наших условиях. И дело не только в том, что отношения между разработчиками и
заказчиками, как и отношения в коллективе разработчиков, в описываемых в книгах
примерах, строятся на несколько иных принципах. Дело скорее в различии
менталитета. Однако адаптация XP к нашим условиям вполне возможна, и это может
дать весьма впечатляющие результаты.
http://xprogramming.com.ua/ — мир
экстремального программирования
http://www.xprogramming.ru/ —
экстремальное программирование по русски
http://www.maxkir.com/ — о разработке
программного обеспечения
http://xprogramming.com/ — сайт
идеолога XP Рона Джеффриса
И другие.
Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код.
1 / 5
Экстремальное программирование (XP) - основные приемы
Hexlet Webinar #6: экстремальное программирование
Life Tips. Зачем участвовать в соревнованиях по программированию?
032. Парное программирование - Сергей Бережной
Канал экстремального программирования v. 2.0
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:
XP предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том, что каждый из них по отдельности работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода, и как он функционирует - в ходе изучения кода тестов логика работы тестируемого кода становится понятной, так как видно, как он должен использоваться. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Функциональные тесты предназначены для тестирования функционирования логики, образуемой взаимодействием нескольких (часто - довольно внушительного размера) частей. Они менее детальны, чем юнит-тесты, но покрывают гораздо больше - то есть, у тестов, которые при своём выполнении затрагивают больший объём кода, шанс обнаружить какое-либо некорректное поведение, очевидно, больше. По этой причине в промышленном программировании написание функциональных тестов нередко имеет больший приоритет, чем написание юнит-тестов.
Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development - разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл. TDD, в некотором смысле, позволяет писать код, более удобный в использовании - потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.
Основная цель игры в планирование - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.
«Заказчик» в XP - это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передаётся от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом парное программирование усиливает взаимодействие внутри команды.
Если выполнять интеграцию разрабатываемой системы достаточно часто, то можно избежать большей части связанных с ней проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
Рефакторинг (refactoring) - это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга в связи с боязнью поломать систему, что приводит к постепенной деградации кода.
Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.
Чем раньше выпускается первая рабочая версия продукта, тем раньше заказчик начинает получать за счёт неё дополнительную прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска.
XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Попытка детально спроектировать систему в самом начале работы является напрасной тратой времени. XP предполагает, что проектирование - это настолько важный процесс, что его необходимо выполнять постоянно в течение всего времени работы над проектом. Проектирование должно выполняться небольшими этапами, с учётом постоянно изменяющихся требований. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются.
Архитектура - это представление о компонентах системы и их взаимосвязях между собой. Разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
Метафора системы (system metaphor) - это аналог того, что в большинстве методик называется архитектурой. Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.
Подбор хорошей метафоры облегчает для группы разработчиков понимание того, каким образом устроена система. Иногда сделать это не просто.
Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнёров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, - вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта.
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код . Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом - в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
