Войти
Экстремальное программирование (XP) - это методология гибкой разработки программного обеспечения, используемая для реализации программного обеспечения проекты. В этой статье подробно описаны практики, используемые в этой методологии. Экстремальное программирование включает 12 практик, сгруппированных в четыре области, основанных на передовых методах из программной инженерии.
Парное программирование означает, что весь код создается tw o люди программируют по одной задаче на одной рабочей станции. Один программист контролирует рабочую станцию и в основном подробно думает о кодировании. Другой программист больше сосредоточен на общей картине и постоянно просматривает код, создаваемый первым программистом. Программисты меняются ролями после минутного времени.
Пары не фиксированы; программисты часто меняют партнеров, так что все знают, что делают, и все остаются знакомыми со всей системой, даже с частями, не соответствующими их навыкам. Таким образом, парное программирование также может улучшить общение в команде. (Это также идет рука об руку с концепцией коллективной собственности).
Основной процесс планирования в рамках экстремального программирования называется игрой в планирование. Игра - это встреча, которая проводится один раз за итерацию, обычно раз в неделю. Процесс планирования разделен на две части:
Цель игры в планирование - привести продукт к доставке. Вместо того, чтобы предсказывать точные даты, когда результаты будут необходимы и произведены, что сложно сделать, он стремится «направить проект» к реализации, используя простой подход. Подход «Игра в планирование» также был принят непрограммными проектами и командами в контексте гибкости бизнеса.
Это итеративный процесс сбора требований и оценка влияния каждого из этих требований на работу.
Когда бизнес не может придумать больше требований, переходят к фазе принятия обязательств.
Этот этап включает определение затрат, выгод и влияния на график. Он состоит из четырех компонентов:
Деловая сторона сортирует пользовательские истории по бизнес-ценности. Они сгруппируют их в три стопки:
Разработчики сортируют пользовательские истории по риску. Они также делятся на три группы: истории пользователей с низким, средним и высоким уровнем риска. Ниже приводится пример подхода к этому:
Все индексы для пользовательской истории добавляются, присваивая пользовательским историям индекс риска низкий (0–1), средний (2–4) или высокий (5–6).
На этапе управления программисты и бизнесмены могут «управлять» процессом. То есть они могут вносить изменения. Индивидуальные пользовательские истории или относительные приоритеты разных пользовательских историй могут измениться; оценки могут оказаться неверными. Это шанс соответствующим образом скорректировать план.
С учетом того, что нужно запланировать точки рассказа о скорости команды. Продолжительность итерации может составлять от 1 до 3 недель.
Этап исследования итерационного планирования заключается в создании задач и оценке времени их выполнения.
На этапе принятия обязательств при планировании итераций программистам назначаются задачи, которые относятся к другому пользователю рассказы.
Реализация задач выполняется во время фазы управления итерацией.
Модульные тесты - это автоматизированные тесты, которые проверяют функциональность частей кода (например, классов, методов). В XP модульные тесты пишутся до того, как кодируется окончательный код. Этот подход призван побудить программиста задуматься об условиях, в которых его или ее код может выйти из строя. XP говорит, что программист закончил работу над определенным фрагментом кода, когда он или она не может придумать никаких дополнительных условий, при которых код может выйти из строя.
Разработка через тестирование осуществляется путем быстрого циклического перехода между следующими этапами, причем каждый этап занимает не более минут, а желательно гораздо меньше. Поскольку для каждой пользовательской истории обычно требуется от одного до двух дней работы, для каждой истории потребуется очень большое количество таких циклов.
Для более интенсивной версии вышеуказанного процесса см. Три правила TDD дяди Боба.
В XP «покупатель» - это не тот, кто оплачивает счет, а тот, кто действительно использует систему. XP говорит, что заказчик должен быть всегда рядом и доступен для вопросов. Например, команда, разрабатывающая систему финансового администрирования, должна включать финансового администратора.
Команда разработчиков всегда должна работать над последней версией программного обеспечения. Поскольку у разных членов команды могут быть версии, сохраненные локально с различными изменениями и улучшениями, им следует пытаться загружать свою текущую версию в репозиторий кода каждые несколько часов или в случае значительного перерыва. Непрерывная интеграция позволит избежать задержек на более позднем этапе проектного цикла, вызванных проблемами интеграции.
Поскольку доктрина XP рекомендует программировать только то, что необходимо сегодня, и реализовывать это как можно проще, иногда это может привести к зависанию системы. Одним из симптомов этого является необходимость двойного (или множественного) обслуживания: функциональные изменения начинают требовать внесения изменений в несколько копий одного и того же (или подобного) кода. Другой симптом заключается в том, что изменения в одной части кода влияют на многие другие части. Доктрина XP гласит, что когда это происходит, система предлагает вам реорганизовать код, изменив архитектуру, сделав его более простым и универсальным.
Поставка программного обеспечения осуществляется через частые выпуски живых функциональных возможностей, создающих конкретную ценность. Небольшие релизы помогают заказчику обрести уверенность в продвижении проекта. Это помогает поддерживать концепцию всей команды, поскольку теперь заказчик может выдвигать свои предложения по проекту на основе реального опыта.
Стандарт кодирования - это согласованный набор правил, которых вся команда разработчиков соглашается придерживаться на протяжении всего проекта. Стандарт определяет согласованный стиль и формат исходного кода в рамках выбранного языка программирования, а также различные программные конструкции и шаблоны, которых следует избегать, чтобы снизить вероятность дефектов. Стандарт кодирования может быть стандартным соглашением, указанным поставщиком языка (например, Соглашение о коде для языка программирования Java, рекомендованным Sun), или пользовательским соглашением, определенным группой разработчиков.
Сторонники экстремального программирования выступают за код, который самодокументируется в максимально возможной степени. Это снижает потребность в комментариях к коду, которые могут не синхронизироваться с самим кодом.
Коллективное владение кодом (также известное как "командный код владение "и" общий код ") означает, что каждый несет ответственность за весь код; поэтому каждый может изменить любую часть кода. Коллективное владение кодом - это не только политика организации, но и чувство. «Разработчики больше ощущают владение кодом команды, когда они понимают контекст системы, внесли свой вклад в рассматриваемый код, воспринимают качество кода как высокое, верят, что продукт удовлетворит потребности пользователей, и ощущают высокую сплоченность команды». Парное программирование, особенно чередование пар с перекрытием, способствует этой практике: работая в разных парах, программисты лучше понимают контекст системы и вносят свой вклад в большее количество областей кодовой базы.
Коллективное владение кодом может ускорить разработку, потому что разработчик, обнаруживший ошибку, может немедленно исправить ее, что может уменьшить количество ошибок в целом. Однако программисты могут также вносить ошибки при изменении кода, который они плохо понимают. Достаточно четко определенные модульные тесты должны смягчить эту проблему: если непредвиденные зависимости создают ошибки, то при запуске модульных тестов они покажут сбои.
Коллективное владение кодом может привести к лучшему резервному копированию участников, более широкому распространению знаний и обучения, совместной ответственности за код, повышению качества кода и уменьшению количества доработок. Но это также может привести к усилению конфликтов между членами, увеличению количества ошибок, изменению мыслей разработчиков и перерывам в их рассуждениях, увеличению времени разработки или меньшему пониманию кода.
Программисты должны придерживаться подхода «простое лучше всего» к разработке программного обеспечения. Каждый раз, когда пишется новый фрагмент кода, автор должен спрашивать себя: «Есть ли более простой способ реализовать ту же функциональность?». Если "да", следует выбрать более простой курс. Для упрощения сложного кода также следует использовать рефакторинг.
Системная метафора - это история, которую каждый - заказчики, программисты и менеджеры - может рассказать о том, как работает система. Это концепция именования классов и методов, которая должна помочь члену команды угадать функциональность определенного класса / метода только по его имени. Например, библиотечная система может создать заемные_записи (класс)для заемщиков (класс), и если элемент станет просроченным, она может выполнить операцию make_overdue в каталоге ( класс). Функциональность каждого класса или операции очевидна для всей команды.
Концепция заключается в том, что программисты или разработчики программного обеспечения не должны работать более 40 часов в неделю, а если в одну неделю есть сверхурочные, то в следующую неделя не должна включать больше сверхурочных. Так как циклы разработки - это короткие циклы непрерывной интеграции, а полные циклы разработки (выпуска) встречаются чаще, проекты в XP не выдерживают типичного времени обработки, которое требуется другим проектам (требуя сверхурочных).
Кроме того, в эту концепцию входит то, что люди работают лучше и креативнее, если они хорошо отдохнули.
Ключевым фактором достижения устойчивого темпа является частое слияние кода, всегда исполняемый и тестируемый код высокого качества. Постоянный рефакторинг работы наделяет членов команды свежим и внимательным умом. Интенсивный способ совместной работы в команде вызывает потребность в подзарядке в выходные.
Хорошо протестированный, постоянно интегрированный, часто развертываемый код и среды также сводят к минимуму частоту неожиданных производственных проблем и простоев, а также необходимую работу в нерабочее время в ночное время и в выходные дни.
