Из-за быстрых изменений в технологиях и требованиях к разработке программного обеспечения разработчики и руководители проектов стремились расширить методологии гибкой разработки. Для этого в середине 1990-х годов была создана компания Extreme Programming. Хотя некоторые называют его первоначальным местом рождения начало 1960-х годов и проект НАСА «Меркурий», он впервые стал популярным благодаря программе Chrysler Comprehensive Compensation (C3).
Когда команда Кента Бека использовала типичную технику водопадной разработки, официально зародилось экстремальное программирование. По мере возникновения проблем команда была вынуждена изменить подход к разработке и возобновить работу с нуля, чтобы сохранить программный проект. В результате родилась техника экстремального программирования, которая распространилась по всему миру разработки программного обеспечения.
Экстремальное программирование (XP) — это подход к разработке программного обеспечения, который направлен на создание лучшего программного обеспечения, а также на улучшение качества жизни команды разработчиков. XP считается одним из наиболее подробных методов разработки программного обеспечения.
Когда применяется XP?
Требования к программному обеспечению, которые постоянно меняются
Экстремальное программирование (XP) было разработано в ответ на проблемные области с постоянно меняющимися потребностями. Ваши потребители могут не иметь представления о том, что должна делать система. Функциональность вашей системы может изменяться каждые несколько месяцев. Единственная константа во многих настройках программного обеспечения — постоянно меняющиеся требования. Именно тогда XP одержит победу над другими методами.
Риски связаны с проектами с установленным сроком, требующим новых технологий.
XP также был создан для решения проблем с рисками проекта. Опасность велика, если вашим клиентам требуется новая система к определенной дате. Опасность значительно выше, если система представляет собой новый вызов для вашей команды разработчиков. Риск еще больше, если эта система бросает новый вызов всему программному бизнесу. Методы XP предназначены для снижения риска и повышения шансов на успех.
Расширенная, но небольшая команда разработчиков.
XP создавался для небольших групп программистов, от 2 до 12 человек. Для проектов со сложными потребностями или высоким риском небольшая команда программистов XP может быть более успешной, чем большая команда, поэтому вы не можете использовать XP для проекта с огромным штатом сотрудников.
С другой стороны, XP требует расширенной команды разработчиков. В команду XP входят не только разработчики, но также менеджеры и заказчики, работающие бок о бок. Чтобы задавать вопросы, согласовывать объем и сроки, а также проводить функциональные тесты, в процессе разработки программного обеспечения должны участвовать не только инженеры.
Модульные и функциональные тесты можно автоматизировать с помощью используемых вами технологий.
Тестируемость — еще один критерий. Вы должны уметь писать модульные и функциональные тесты, которые будут автоматизированы. В некоторых областях вам придется проявить некоторую изобретательность в тестировании или изменить дизайн вашей системы, чтобы упростить тестирование.
По сравнению с аналогичными проектами в одной и той же компании, проекты XP постоянно демонстрируют более высокую производительность. Однако производительность никогда не была главным приоритетом методологии XP. Истинная цель всегда заключалась в том, чтобы предоставить программное обеспечение, которое необходимо, когда оно необходимо.
Ценности:
XP опирается на 5 ценностей: общение, простота, обратная связь, смелость и уважение.
Общение
По своей сути разработка программного обеспечения — это командный вид спорта, основанный на общении для передачи информации от одного члена команды к остальной команде. XP подчеркивает важность правильной формы общения — беседы лицом к лицу.
Простота
Цель состоит в том, чтобы сократить потери и выполнить только то, что необходимо, например, сохранить системную архитектуру как можно более простой, чтобы упростить ее обслуживание, поддержку и изменение. Простота также включает в себя работу только с известными требованиями, а не попытки предсказать, что может возникнуть в будущем.
Отзыв
Команды могут находить области для развития и обновлять свои процедуры, постоянно получая отзывы о своих предыдущих усилиях. Команда что-то создает, собирает информацию о дизайне и реализации, а затем корректирует продукт по мере необходимости.
Мужество
Чтобы поднять организационные проблемы, которые ограничивают производительность вашей команды, вам потребуется мужество. Вы должны иметь мужество отказаться от того, что не работает, и попробовать что-то новое. Чтобы принять обратную связь и действовать в соответствии с ней, особенно когда ее трудно принять, требуется мужество.
Уважение
Члены команды должны уважать друг друга, чтобы общаться, предлагать и принимать критику, которая делает ваши отношения ценными, и работать вместе над разработкой простых проектов и решений.
Практики XP, которые могут помочь в ежедневном рабочем процессе компании-разработчика программного обеспечения
С тех пор, как они были впервые установлены, практики XP немного изменились. Второе издание книги «Объяснение экстремального программирования: принятие изменений» определяет 13 основных практик XP, а именно: сидеть вместе, всей командой, информативное рабочее пространство, энергичная работа, парное программирование, истории, недельный цикл, квартальный цикл, Slack, десятиминутная сборка, Непрерывная интеграция, программирование с первым тестом и инкрементный дизайн.
Доказано, что все вышеперечисленные практики приносят высокий уровень производительности командам разработчиков, 3 из которых будут рассмотрены ниже.
Парное программирование
Процесс двух разработчиков, работающих одновременно на одной рабочей станции, известен как парное программирование. Они будут вместе разрабатывать, отлаживать и исследовать код, выполняя каждую работу по очереди. Пока один разработчик работает, другой наблюдает, учится и помогает.
Преимущества:
● Повышает устойчивость команды за счет обмена знаниями.
● Участие разработчиков в проекте можно повысить за счет коллективного владения кодом.
● Непрерывная проверка кода помогает уменьшить количество ошибок.
● Повышение эффективности достигается за счет короткого цикла обратной связи, который является частью проверки кода в реальном времени.
● Расширенные возможности обучения и общения
Проблемы
● Возможна отстраненность или «следите за поведением хозяина». Это происходит, когда один разработчик берет на себя основное управление проектом, а другой наблюдает, а не практикует и не учится.
● Когда разработчики не взаимодействуют друг с другом по поводу своих процессов или когда возникают разногласия относительно их подхода к построению или отладке, общение может прерваться.
Программирование в первую очередь
Создание автоматических модульных тестов для производственного кода перед его написанием называется программированием с первым тестом. Это циклический процесс автоматизированных модульных тестов для поиска ошибок в коде до того, как он будет подготовлен для производства. Вместо того, чтобы создавать тесты позже, вы всегда начинаете с модульного теста. Вы должны разработать и выполнить короткий (желательно очень небольшой) целевой тест для каждой крошечной части функциональности в рабочем коде, который определяет и подтверждает, что код будет выполнять.
Затем вы получаете его для сборки, используя только самый простой производственный код, поэтому вы можете запустить его и посмотреть, как он выйдет из строя. (Иногда вы ожидаете, что он потерпит неудачу, но он успешен, что является полезной информацией.) Затем вы пишете ровно столько кода, сколько требуется для прохождения теста.
Ниже приведены шаги этой процедуры:
● Создайте автоматический тест, который не пройден.
● Выполните неудачный тест.
● Создайте код, который позволит пройти тест.
● Выполните тест
● Повторить
Преимущества
● Сокращает время, необходимое разработчикам для обнаружения и устранения проблем, за счет сокращения цикла обратной связи.
● Сокращает количество ошибок, запускаемых в производство.
Проблемы
● Для понимания и применения процедуры требуется крутая кривая обучения.
● Для этого требуется больше кода, чем для других методологий разработки.
● Если высшее руководство не желает перемен или не понимает преимуществ «отсталой» стратегии, может быть трудно заручиться их поддержкой.
Непрерывная интеграция (CI)
Непрерывная интеграция — это процесс быстрого тестирования небольших изменений кода и их применения к большей кодовой базе. Это автоматизированная процедура, в которой многочисленные модификации кода участников объединяются в один программный проект. Непрерывная интеграция обычно используется в сочетании с непрерывной доставкой (CD), чтобы гарантировать, что код тестируется и доставляется небольшими порциями высокого качества.
Преимущества
● Автоматическая интеграция позволяет сразу же тестировать код.
● Возможность более раннего выявления и решения проблем
● После сборки требуется меньше корректировок.
Проблемы
● Требуется сила воли, чтобы внести исправления, как только они будут обнаружены.
● Существует вероятность того, что некоторые тесты будут ошибочными. Когда тесты плохо разработаны, устарели или не подходят для определенного приложения, этот риск возрастает.
● Проблемы с контролем версий. Большинство процедур CI/CD были созданы для определенной версии приложения, и их нужно было корректировать для более новых версий.
XP предоставляет набор методов, которые позволяют разработчикам работать более эффективно и создавать более качественное программное обеспечение. Кроме того, XP фокусируется на практике совершенства. Это побуждает команды выполнять эти практики как можно лучше, можно сказать, очень хорошо. Название происходит с этой точки зрения, а не из-за того, что методы XP являются экстремальными, а из-за постоянного внимания команд к постоянному совершенствованию в отношении улучшения их способности выполнять эти методы.
