Экстремальное программирование - практика

Есть четыре основных вида деятельности в экстремальном программировании. Они -

  • кодирование

  • тестирование

  • Listening

  • Проектирование

Эти четыре основных действия должны быть структурированы в свете принципов экстремального программирования. Для этого определены методы экстремального программирования.

Эти 12 практик экстремального программирования достигают цели экстремального программирования, и там, где одна из практик слаба, сильные стороны других практик восполнят ее.

Кент Бек, автор «Объяснения экстремального программирования», определил 12 практик экстремального программирования следующим образом:

  • Игра в планирование

  • Короткие Релизы

  • метафора

  • Простой дизайн

  • тестирование

  • Рефакторинг

  • Парное программирование

  • Коллективная собственность

  • Непрерывная интеграция

  • 40 часовая неделя

  • Клиент на месте

  • Стандарты кодирования

Четыре области экстремального программирования

Практики экстремального программирования можно разделить на четыре области:

  • Быстрая, Прекрасная Обратная Связь -

    • тестирование

    • Клиент на месте

    • Парное программирование

  • Непрерывный процесс -

    • Непрерывная интеграция

    • Рефакторинг

    • Короткие Релизы

  • Общее понимание -

    • Игра в планирование

    • Простой дизайн

    • метафора

    • Коллективная собственность

    • Стандарты кодирования

  • Благосостояние разработчика -

    • Сорокчасовая неделя

В этой главе вы познакомитесь с методами экстремального программирования в деталях и преимуществами каждого из этих методов.

Экстремальные практики программирования с первого взгляда

Следующая диаграмма показывает, как экстремальное программирование сплетено с практиками экстремального программирования:

Экстремальные практики программирования

Игра в планирование

Основной процесс планирования в рамках экстремального программирования называется «Игра в планирование». Игра - это встреча, которая происходит один раз за итерацию, обычно раз в неделю. Игра «Планирование» позволяет быстро определить объем следующего выпуска, объединив бизнес-приоритеты и технические оценки. Когда реальность настигнет план, обновите план.

Бизнес и развитие должны принимать решения в тандеме. Бизнес-решения и технические решения разработки должны согласовываться друг с другом.

Деловые люди должны решить о -

  • Масштаб - Какую часть проблемы нужно решить, чтобы система была ценной в производстве? Бизнесмен в состоянии понять, сколько не достаточно, а что слишком много.

  • Приоритет - если вам предоставляется вариант, какой из них вы хотите? Бизнесмен в состоянии определить это, больше, чем разработчик при участии клиента.

  • Состав релизов - Сколько или сколько нужно сделать, чтобы бизнес стал лучше с программным обеспечением, чем без него? Интуиция разработчика по этому вопросу может быть совершенно неверной.

  • Даты выпусков - Какие важные даты, в которые присутствие программного обеспечения (или часть программного обеспечения) будет иметь большое значение?

Технические люди должны решить о -

  • Оценки - Сколько времени займет реализация функции?

  • Последствия - Существуют стратегические бизнес-решения, которые должны приниматься только при условии информирования о технических последствиях. Развитие должно объяснить последствия.

  • Процесс - Как будет организована работа и команда? Команда должна соответствовать культуре, в которой она будет действовать. Программное обеспечение должно быть написано хорошо, а не сохранять иррациональность замкнутой культуры.

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

Таким образом, план является результатом сотрудничества между заказчиком, бизнесменом и разработчиками.

Игра в планирование - преимущества

Игра в планирование имеет следующие преимущества:

  • Сокращение времени, потраченное впустую на бесполезные функции

  • Большая оценка клиентов стоимости функции

  • Меньше догадок при планировании

Короткие Релизы

Вы должны быстро запустить простую систему в производство, а затем выпускать новые версии очень короткими циклами. Каждый выпуск должен быть как можно меньше, чтобы он -

  • Достижимо за короткий цикл

  • Содержит самые ценные и актуальные бизнес-требования

  • Рабочая система

Продолжительность короткого цикла может варьироваться в зависимости от программного обеспечения, которое необходимо построить. Однако необходимо обеспечить выбор минимально возможной продолжительности.

Короткие Релизы - Преимущества

Преимущества коротких релизов -

  • Частые отзывы

  • отслеживание

  • Уменьшить вероятность общего проскальзывания проекта

метафора

Согласно интернет-словарю Кембриджа, метафора - это выражение, часто встречающееся в литературе, которое описывает человека или объект, ссылаясь на то, что, как считается, имеет сходные характеристики с этим человеком или объектом. Например, «ум - это океан» и «город - джунгли» - это и есть метафоры.

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

Метафора состоит из специфичных для предметной области элементов и показывает их взаимосвязь. Используемый язык является языком домена. Чтобы идентифицировать технические объекты, слова, используемые в метафоре, должны восприниматься последовательно.

По мере развития и развития метафоры вся команда обретет новое вдохновение от изучения метафоры.

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

Метафора - преимущества

Преимущества Метафоры -

  • Поощряет общий набор терминов для системы

  • Сокращение модных слов и жаргона

  • Быстрый и простой способ объяснить систему

Простой дизайн

Система должна быть спроектирована максимально просто в любой момент. Дополнительная сложность удаляется, как только она обнаружена.

Правильный дизайн программного обеспечения в любой момент времени - это тот, который -

  • Запускает все тесты

  • Не имеет дублированной логики, такой как параллельные иерархии классов

  • Излагает все намерения, важные для разработчиков

  • Имеет как можно меньше классов и методов

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

Простой дизайн - преимущества

Преимущества простого дизайна -

  • Время не теряется, добавляя лишнюю функциональность

  • Проще понять, что происходит

  • Рефакторинг и коллективная собственность стала возможной

  • Помогает держать программистов на ходу

тестирование

Разработчики постоянно пишут юнит-тесты, которые необходимо пройти для продолжения разработки. Клиенты пишут тесты, чтобы убедиться, что эти функции реализованы. Тесты автоматизированы, так что они становятся частью системы и могут непрерывно запускаться для обеспечения работы системы. В результате получается система, способная принимать изменения.

Тестирование - преимущества

Преимущества тестирования:

  • Модульное тестирование способствует полноте тестирования

  • Test-first дает разработчикам цель

  • Автоматизация дает набор регрессионных тестов

Рефакторинг

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

Рефакторинг - преимущества

Преимущества рефакторинга -

  • Предлагает разработчикам активно улучшать продукт в целом

  • Увеличивает знания разработчиков системы

Парное программирование

При парном программировании весь код пишется двумя разработчиками на одной машине, с одной клавиатурой и одной мышью.

В каждой паре две роли -

  • Первый разработчик (с клавиатурой и мышью) думает о том, как лучше реализовать этот метод прямо здесь.

  • Другой разработчик думает более стратегически

    • Весь этот подход будет работать?

    • Какие еще тестовые примеры могут еще не работать?

    • Есть ли способ упростить всю систему, чтобы текущая проблема просто исчезла?

Спаривание динамическое. Это означает, что две роли A и B могут поменяться местами или объединиться с другими членами команды. Чаще кто-либо в команде будет выступать в качестве партнера. Например, если вы несете ответственность за выполнение задачи в незнакомой вам области, вы можете попросить кого-то с недавним опытом объединиться с вами.

Парное программирование - преимущества

Преимущества парного программирования -

  • Одна голова хорошо, а две - лучше

  • фокус

  • Два человека с большей вероятностью ответят на следующие вопросы -

    • Весь этот подход будет работать?

    • Какие тестовые случаи могут еще не работать?

    • Есть ли способ упростить это?

Коллективная собственность

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

Если пара работает, и они видят возможность улучшить код, они идут дальше и улучшают его.

Коллективное владение - преимущества

Преимущества коллективной собственности -

  • Помогает смягчить потерю члена команды, который уходит.

  • Предлагает разработчикам взять на себя ответственность за систему в целом, а не за ее части.

Непрерывная интеграция

Код интегрируется и тестируется много раз в день, по одному набору изменений за раз. Простой способ сделать это - иметь машину, предназначенную для интеграции. Пара с кодом, готовым к интеграции -

  • Сидит, когда машина свободна.

  • Загружает текущий выпуск.

  • Загружает их изменения (проверка и устранение любых коллизий).

  • Запускает тесты до тех пор, пока они не пройдут (100% правильно).

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

Непрерывная интеграция - преимущества

Преимущества непрерывной интеграции -

  • Уменьшает продолжительность, которая в противном случае является длительной.

  • Включает практику коротких выпусков, так как время, необходимое для выпуска, минимально.

40-часовая неделя

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

40-часовая неделя - преимущества

Преимущества 40-часовой недели -

  • Большинство разработчиков теряют эффективность за последние 40 часов.

  • Ценность придается благосостоянию разработчиков.

  • Менеджмент вынужден находить реальные решения.

Клиент на месте

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

Клиент на месте - преимущества

Преимущества наличия местного клиента -

  • Может дать быстрые и знающие ответы на реальные вопросы развития.

  • Уверен, что то, что разработано, то, что нужно.

  • Функциональность расставлена по приоритетам правильно.

Стандарты кодирования

Разработчики пишут весь код в соответствии с правилами, подчеркивающими

  • Связь через код.

  • Наименьшее количество работы возможно.

  • В соответствии с правилом «один раз и только один раз» (без дублирующего кода).

  • Добровольное усыновление всей командой.

Эти правила необходимы в экстремальном программировании, потому что все разработчики -

  • Может переключаться с одной части системы на другую часть системы.

  • Меняйте партнеров пару раз в день.

  • Рефакторинг кода друг друга постоянно.

Если правила не будут соблюдаться, разработчики будут склонны придерживаться разных наборов методов кодирования, со временем код становится непоследовательным, и становится невозможным сказать, кто из команды написал какой код.

Стандарты кодирования - Преимущества

Преимущества стандартов кодирования -

  • Сокращает время, которое разработчики тратят на переформатирование кода других людей.

  • Уменьшает необходимость внутреннего комментирования.

  • Призывает к ясному, однозначному коду.