Экстремальное программирование ( XP ) — это методология разработки программного обеспечения , направленная на улучшение качества программного обеспечения и реагирования на изменяющиеся требования клиентов. Как тип гибкой разработки программного обеспечения , [1] [2] [3] он выступает за частые релизы в коротких циклах разработки, направленных на повышение производительности и введение контрольных точек, в которых могут быть приняты новые требования клиентов.
Другие элементы экстремального программирования включают в себя парное программирование или выполнение обширного обзора кода , модульное тестирование всего кода, не программирование функций до тех пор, пока они действительно не понадобятся , плоская структура управления, простота и ясность кода, ожидание изменений в требованиях заказчика с течением времени и лучшего понимания проблемы, а также частое общение с заказчиком и между программистами. [2] [3] [4] Название методологии происходит от идеи, что полезные элементы традиционных практик разработки программного обеспечения доводятся до «экстремальных» уровней. Например, обзоры кода считаются полезной практикой; доведенный до крайности, код может проверяться непрерывно (т. е. практика парного программирования ).
Кент Бек разработал экстремальное программирование во время своей работы над проектом по расчету заработной платы Chrysler Comprehensive Compensation System (C3) . [5] Бек стал руководителем проекта C3 в марте 1996 года. Он начал совершенствовать методологию разработки, используемую в проекте, и написал книгу о методологии ( Extreme Programming Explained , опубликована в октябре 1999 года). [5] Chrysler отменил проект C3 в феврале 2000 года, спустя семь лет, когда Daimler-Benz приобрела компанию. [6] Уорд Каннингем оказал еще одно большое влияние на XP.
Многие практики экстремального программирования существуют уже некоторое время; методология выводит « лучшие практики » на экстремальный уровень. Например, «практика разработки с тестированием, планирования и написания тестов перед каждым микрошагом» использовалась еще в проекте NASA Mercury в начале 1960-х годов. [7] Чтобы сократить общее время разработки, некоторые формальные тестовые документы (например, для приемочного тестирования ) были разработаны параллельно (или незадолго до) готовности программного обеспечения к тестированию. Независимая группа тестирования NASA может написать процедуры тестирования на основе формальных требований и логических ограничений до того, как программисты напишут программное обеспечение и интегрируют его с оборудованием. XP выводит эту концепцию на экстремальный уровень, создавая автоматизированные тесты (иногда внутри программных модулей), которые проверяют работу даже небольших разделов программного кода, а не только тестируют более крупные функции.
На разработку программного обеспечения в 1990-х годах оказали влияние два основных фактора:
Быстро меняющиеся требования требовали сокращения жизненного цикла продуктов и часто вступали в противоречие с традиционными методами разработки программного обеспечения.
Система комплексной компенсации Chrysler (C3) была запущена для определения наилучшего способа использования объектных технологий, используя системы расчета заработной платы в Chrysler в качестве объекта исследования, с Smalltalk в качестве языка и GemStone в качестве уровня доступа к данным . Chrysler привлек Кента Бека [5] , известного специалиста по Smalltalk, для настройки производительности системы, но его роль расширилась, поскольку он заметил несколько проблем с процессом разработки. Он воспользовался этой возможностью, чтобы предложить и внедрить некоторые изменения в практику разработки - на основе своей работы с его постоянным соавтором Уордом Каннингемом . Бек описывает раннюю концепцию методов: [8]
В первый раз, когда меня попросили возглавить команду, я попросил их сделать немного того, что я считал разумным, например, тестирование и обзоры. Во второй раз на кону было гораздо больше. Я подумал: «К черту торпеды, по крайней мере, это будет хорошая статья», [и] попросил команду выкрутить все ручки на 10 на вещах, которые я считал важными, и выбросить все остальное.
Бек пригласил Рона Джеффриса в проект, чтобы тот помог разработать и усовершенствовать эти методы. После этого Джеффрис выступил в качестве тренера, чтобы внедрить эти практики в качестве привычек в команду C3.
Информация о принципах и методах, лежащих в основе XP, распространялась по всему миру через обсуждения на оригинальной вики , WikiWikiWeb Каннингема . Различные участники обсуждали и развивали идеи, и в результате появились некоторые побочные методологии (см. agile software development ). Кроме того, концепции XP объяснялись [ кем? ] в течение нескольких лет с использованием гипертекстовой системной карты на веб-сайте XP по адресу http://www.extremeprogramming.org c. 1999 .
Бек редактировал серию книг по XP, начиная с его собственной Extreme Programming Explained (1999, ISBN 0-201-61641-6 ), распространяя свои идеи на гораздо более широкую аудиторию. Авторы в серии рассмотрели различные аспекты, связанные с XP и его практиками. Серия включала книгу, критикующую практики.
XP вызвала значительный интерес среди сообществ разработчиков программного обеспечения в конце 1990-х и начале 2000-х годов, поскольку ее внедрение в ряде сред радикально отличалось от ее истоков.
Высокая дисциплина, требуемая исходными практиками, часто отходила на второй план, в результате чего некоторые из этих практик, например, те, которые считались слишком жесткими, были отменены или сокращены, или даже оставлены незавершенными на отдельных сайтах. Например, практика интеграционных тестов в конце дня для конкретного проекта могла быть изменена на график в конце недели или просто сведена к тестированию в согласованные даты. Такой более свободный график мог бы избежать ощущения, что люди торопятся создавать искусственные заглушки только для того, чтобы пройти тестирование в конце дня. Менее жесткий график позволяет вместо этого разрабатывать сложные функции в течение нескольких дней.
Между тем, другие практики гибкой разработки не стояли на месте, и по состоянию на 2019 год [update]XP продолжает развиваться, усваивая больше уроков из опыта в этой области, чтобы использовать другие практики. Во втором издании Extreme Programming Explained (ноябрь 2004 г.), спустя пять лет после первого издания, Бек добавил больше ценностей и практик и провел различие между основными и сопутствующими практиками.
В книге «Объяснение экстремального программирования» экстремальное программирование описывается как дисциплина разработки программного обеспечения, которая организует людей для более продуктивного создания высококачественного программного обеспечения.
XP пытается снизить стоимость изменений в требованиях, используя несколько коротких циклов разработки вместо одного длинного. В этой доктрине изменения являются естественным, неизбежным и желательным аспектом проектов по разработке ПО, и их следует планировать, а не пытаться определить стабильный набор требований.
Экстремальное программирование также вводит ряд базовых ценностей, принципов и практик, выходящих за рамки гибкой методологии.
XP описывает четыре основных действия, которые выполняются в процессе разработки ПО: кодирование, тестирование, прослушивание и проектирование. Каждое из этих действий описано ниже.
Сторонники XP утверждают, что единственным действительно важным продуктом процесса разработки системы является код — программные инструкции, которые может интерпретировать компьютер. Без кода нет работающего продукта.
Кодирование может использоваться для поиска наиболее подходящего решения. Кодирование также может помочь в передаче мыслей о проблемах программирования. Программист, имеющий дело со сложной проблемой программирования или которому трудно объяснить решение другим программистам, может закодировать ее упрощенным способом и использовать код для демонстрации того, что они имеют в виду. Код, говорят сторонники этой позиции, всегда ясен и лаконичен и не может быть интерпретирован более чем одним способом. Другие программисты могут дать обратную связь по этому коду, также закодировав свои мысли.
Тестирование играет центральную роль в экстремальном программировании. [9] Подход экстремального программирования заключается в том, что если небольшое тестирование может устранить несколько недостатков, то большое тестирование может устранить гораздо больше недостатков.
Тестирование интеграции всей системы изначально поощрялось как ежедневная деятельность в конце дня для раннего обнаружения несовместимых интерфейсов, чтобы повторно подключиться до того, как отдельные разделы сильно отклонятся от согласованной функциональности. Однако тестирование интеграции всей системы было сокращено до еженедельного или менее частого, в зависимости от стабильности общих интерфейсов в системе. [ необходима цитата ]
Программисты должны прислушиваться к тому, что система должна делать клиентам, какая " бизнес-логика " нужна. Они должны понимать эти потребности достаточно хорошо, чтобы дать клиенту обратную связь о технических аспектах того, как проблема может быть решена или не может быть решена. Коммуникация между клиентом и программистом далее рассматривается в игре планирования .
С точки зрения простоты, конечно, можно сказать, что разработка системы не требует ничего, кроме кодирования, тестирования и прослушивания. Если эти действия выполняются хорошо, результатом всегда должна быть работающая система. На практике это не сработает. Можно пройти долгий путь без проектирования, но в определенный момент можно застрять. Система становится слишком сложной, и зависимости внутри системы перестают быть ясными. Этого можно избежать, создав структуру дизайна, которая организует логику в системе. Хороший дизайн позволит избежать многих зависимостей внутри системы; это означает, что изменение одной части системы не повлияет на другие части системы. [ необходима цитата ]
Экстремальное программирование изначально признало четыре ценности в 1999 году: общение, простота, обратная связь и смелость. Новая ценность, уважение, была добавлена во втором издании Extreme Programming Explained . Эти пять ценностей описаны ниже.
Создание систем программного обеспечения требует сообщения системных требований разработчикам системы. В формальных методологиях разработки программного обеспечения эта задача выполняется с помощью документации. Методы экстремального программирования можно рассматривать как методы быстрого создания и распространения институциональных знаний среди членов команды разработчиков. Цель состоит в том, чтобы дать всем разработчикам общее представление о системе, которое соответствует представлению пользователей системы. С этой целью экстремальное программирование благоприятствует простым проектам, общим метафорам, сотрудничеству пользователей и программистов, частому устному общению и обратной связи.
Экстремальное программирование поощряет начинать с самого простого решения. Дополнительную функциональность можно добавить позже. Разница между этим подходом и более традиционными методами разработки систем заключается в фокусировке на проектировании и кодировании для нужд сегодняшнего дня, а не для нужд завтрашнего дня, следующей недели или следующего месяца. Иногда это называют подходом « Вам это не понадобится » (YAGNI). [10] Сторонники XP признают недостаток, заключающийся в том, что это иногда может повлечь за собой больше усилий завтра для изменения системы; они утверждают, что это более чем компенсируется преимуществом не инвестировать в возможные будущие требования, которые могут измениться до того, как они станут актуальными. Кодирование и проектирование для неопределенных будущих требований подразумевает риск траты ресурсов на то, что может не понадобиться, при этом, возможно, задерживая важные функции. В связи со значением «коммуникации» простота в проектировании и кодировании должна улучшить качество коммуникации. Простой дизайн с очень простым кодом может быть легко понятен большинству программистов в команде.
В экстремальном программировании обратная связь касается различных аспектов разработки системы:
Обратная связь тесно связана с коммуникацией и простотой. О недостатках в системе легко сообщить, написав модульный тест, который доказывает, что определенный фрагмент кода сломается. Прямая обратная связь от системы говорит программистам, что нужно перекодировать эту часть. Клиент может периодически тестировать систему в соответствии с функциональными требованиями, известными как пользовательские истории . [5] По словам Кента Бека , «Оптимизм — это профессиональный риск программирования. Обратная связь — это лечение». [11]
Несколько практик воплощают смелость. Одна из них — заповедь всегда проектировать и кодировать для сегодняшнего дня, а не для завтрашнего. Это попытка избежать увязания в дизайне и необходимости больших усилий для реализации чего-либо еще. Смелость позволяет разработчикам чувствовать себя комфортно при рефакторинге своего кода, когда это необходимо. [5] Это означает проверку существующей системы и ее изменение, чтобы в будущем можно было легче внедрять изменения. Еще один пример смелости — знание того, когда следует выбросить код: смелость удалить исходный код, который устарел, независимо от того, сколько усилий было потрачено на его создание. Кроме того, смелость означает настойчивость: программист может застрять на сложной проблеме на целый день, а затем быстро решить ее на следующий день, но только если он настойчив.
Значение уважения включает уважение к другим, а также к самоуважению. Программисты никогда не должны вносить изменения, которые нарушают компиляцию, заставляют существующие модульные тесты не работать или иным образом задерживают работу их коллег. Участники уважают свою собственную работу, всегда стремясь к высокому качеству и стремясь к лучшему дизайну для имеющегося решения посредством рефакторинга.
Принятие четырех предыдущих ценностей ведет к уважению со стороны других членов команды. Никто в команде не должен чувствовать себя недооцененным или проигнорированным. Это обеспечивает высокий уровень мотивации и поощряет лояльность к команде и цели проекта. Эта ценность зависит от других ценностей и ориентирована на командную работу.
Первая версия правил для XP была опубликована в 1999 году Доном Уэллсом [12] на веб-сайте XP. 29 правил даны в категориях планирования, управления, проектирования, кодирования и тестирования. Планирование, управление и проектирование упоминаются явно, чтобы опровергнуть заявления о том, что XP не поддерживает эти виды деятельности.
Другая версия правил XP была предложена Кеном Ауэром [13] в XP/Agile Universe 2003. Он считал, что XP определяется его правилами, а не его практиками (которые подвержены большему разнообразию и двусмысленности). Он определил две категории: «Правила взаимодействия», которые диктуют среду, в которой разработка программного обеспечения может происходить эффективно, и «Правила игры», которые определяют ежеминутные действия и правила в рамках Правил взаимодействия.
Вот некоторые из правил (неполные):
Кодирование
Тестирование
Принципы, которые составляют основу XP, основаны на только что описанных ценностях и предназначены для содействия принятию решений в проекте разработки системы. Принципы должны быть более конкретными, чем ценности, и их легче переводить в руководство в практической ситуации.
Экстремальное программирование считает обратную связь наиболее полезной, если она делается часто и быстро. Оно подчеркивает, что минимальная задержка между действием и его обратной связью имеет решающее значение для обучения и внесения изменений. В отличие от традиционных методов разработки систем, контакт с заказчиком происходит в более частых итерациях. Заказчик имеет четкое представление о разрабатываемой системе и может давать обратную связь и направлять разработку по мере необходимости. При частой обратной связи от заказчика ошибочное проектное решение, принятое разработчиком, будет быстро замечено и исправлено, прежде чем разработчик потратит много времени на его реализацию.
Модульные тесты способствуют принципу быстрой обратной связи. При написании кода запуск модульного теста обеспечивает прямую обратную связь относительно того, как система реагирует на внесенные изменения. Это включает в себя запуск не только модульных тестов, которые проверяют код разработчика, но и запуск в дополнение ко всему модульному тестированию всего программного обеспечения с использованием автоматизированного процесса, который может быть инициирован одной командой. Таким образом, если изменения разработчика вызывают сбой в какой-то другой части системы, о которой разработчик знает мало или совсем ничего, автоматизированный набор всех модульных тестов немедленно выявит сбой, предупредив разработчика о несовместимости его изменения с другими частями системы и о необходимости удаления или изменения его изменения. В рамках традиционных методов разработки отсутствие автоматизированного, всеобъемлющего набора модульных тестов означало, что такое изменение кода, которое разработчик считал безвредным, оставалось бы на месте, появляясь только во время интеграционного тестирования — или, что еще хуже, только в производстве; и определение того, какое изменение кода вызвало проблему, среди всех изменений, внесенных всеми разработчиками в течение недель или даже месяцев, предшествовавших интеграционному тестированию, было сложной задачей.
Речь идет о том, чтобы рассматривать каждую проблему так, как будто ее решение «чрезвычайно простое». Традиционные методы разработки систем говорят о планировании будущего и кодировании для повторного использования. Экстремальное программирование отвергает эти идеи.
Сторонники экстремального программирования говорят, что внесение больших изменений сразу не работает. Экстремальное программирование применяет постепенные изменения: например, система может выпускать небольшие релизы каждые три недели. Когда делается много маленьких шагов, у заказчика больше контроля над процессом разработки и разрабатываемой системой.
Принцип принятия изменений заключается в том, чтобы не работать против изменений, а принимать их. Например, если на одной из итеративных встреч выяснится, что требования заказчика кардинально изменились, программисты должны принять это и запланировать новые требования для следующей итерации.
Экстремальное программирование описывается как состоящее из 12 практик, сгруппированных в четыре области:
Практики XP были предметом интенсивных споров. [5] Сторонники экстремального программирования утверждают, что, если клиент на месте [5] запрашивает изменения неформально, процесс становится гибким и экономит формальные накладные расходы. Критики XP утверждают, что это может привести к дорогостоящим переделкам и выходу масштаба проекта за рамки того, что было согласовано или профинансировано ранее. [ необходима цитата ]
Доски управления изменениями являются признаком того, что существуют потенциальные конфликты в целях и ограничениях проекта между несколькими пользователями. Ускоренные методы XP в некоторой степени зависят от способности программистов принять единую точку зрения клиента, чтобы программист мог сосредоточиться на кодировании, а не на документации компромиссных целей и ограничений. [14] Это также применимо, когда задействовано несколько организаций по программированию, особенно организаций, которые конкурируют за доли в проектах. [ необходима цитата ]
Другие потенциально спорные аспекты экстремального программирования включают в себя:
Критики отметили несколько потенциальных недостатков, [5] включая проблемы с нестабильными требованиями, отсутствие документированных компромиссов в конфликтах пользователей и отсутствие общей спецификации или документа по проектированию.
Thoughtworks заявила о достаточном успехе в распределенных проектах XP с участием до шестидесяти человек. [ необходима цитата ]
В 2004 году было представлено промышленное экстремальное программирование (IXP) [15] как эволюция XP. Оно призвано обеспечить возможность работы в больших и распределенных командах. Сейчас оно имеет 23 практики и гибкие значения.
В 2003 году Мэтт Стивенс и Дуг Розенберг опубликовали книгу Extreme Programming Refactored: The Case Against XP , в которой подвергли сомнению ценность процесса XP и предложили пути его улучшения. [6] Это вызвало продолжительные дебаты в статьях, новостных группах Интернета и чатах на веб-сайтах. Основной аргумент книги заключается в том, что практики XP взаимозависимы, но лишь немногие практические организации готовы/способны принять все практики; поэтому весь процесс терпит неудачу. В книге также высказываются другие критические замечания, и она проводит аналогию между моделью «коллективной собственности» XP и социализмом в негативном ключе.
Некоторые аспекты XP изменились с момента публикации Extreme Programming Refactored ; в частности, теперь XP допускает изменения практик, пока требуемые цели все еще выполняются. XP также использует все более общие термины для процессов. Некоторые утверждают, что эти изменения сводят на нет предыдущие критические замечания; другие утверждают, что это просто разбавляет процесс.
Другие авторы пытались примирить XP со старыми методологиями, чтобы сформировать единую методологию. Некоторые из них XP пытались заменить, например, методологию водопада ; например: Project Lifecycles: Waterfall, Rapid Application Development (RAD) и все такое. JPMorgan Chase & Co. попытались объединить XP с методами компьютерного программирования интеграции модели зрелости возможностей (CMMI) и Six Sigma . Они обнаружили, что три системы хорошо усиливают друг друга, что приводит к лучшей разработке и не противоречат друг другу. [16]
Первоначальный шум вокруг экстремального программирования и его противоречивые принципы, такие как парное программирование и непрерывное проектирование , вызвали особую критику, например, от Макбрина, [17] Бёма и Тернера, [18] Мэтта Стивенса и Дуга Розенберга. [19] Однако многие из критических замечаний, по мнению практикующих Agile, являются следствием неправильного понимания гибкой разработки. [20]
В частности, экстремальное программирование было рассмотрено и подвергнуто критике в книге Мэтта Стивенса и Дуга Розенберга «Рефакторинг экстремального программирования» . [6]
{{cite book}}: |work=проигнорировано ( помощь )
