Когда обнаружена ошибка
Если обнаруживается ошибка, то создается тест, чтобы предотвратить ее повторное появление. Ошибка, произошедшая в рабочей системе (уже установленной), требует написания функционального теста. Создание функционального теста непосредственно перед диагностикой ошибки позволяет заказчикам четко описать проблему и довести эту проблему до разработчиков.
Невыполнившийся функциональный тест требует создания Unit Test. Это помогает сфокусировать усилия по отладке и четко показывает когда ошибка исправлена.
6. Реорганизация (refactoring) — способ улучшения программного кода, без изменения его функциональности; цель — устранить дублирование, избыточность, неиспользуемый код, улучшить взаимодействие, упростить систему или добавить в нее гибкость. XP-процесс подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Ясный и понятный код легче модифицировать и расширять.
7. Парное программирование (pair programming). Весь код пишется двумя программистами, работающими на одном компьютере.Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. Если по какой-то причине второй из пары пропустил что-то (болел, отходил и т.п.), он обязан просмотреть все изменения сделанные первым. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Это можно отнести к коллективному владению. Может показаться, что парное программирование удваивает ресурсы, но исследования доказали: парное программирование приводит к повышению качества и уменьшению времени цикла. Сотрудничество улучшает процесс решения проблем, улучшение качества существенно снижает затраты сопровождения, которые превышают стоимость дополнительных ресурсов по всему циклу разработки.
Таким образом, парное программирование усиливает взаимодействие внутри команды, пары обычно находят более оптимальные решения, существенно увеличивается качество кода, снижается число ошибок и ускоряется обмен знаниями между разработчиками.
8. Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.
Коллективное владение означает, что любой разработчик может изменять любой фрагмент кода системы в любое время. Непрерывная интеграция, непрерывное регрессионное тестирование и парное программирование ХР обеспечивают защиту от возникающих при этом проблем.
Коллективное владение
Коллективное владениеозначает, что каждый член команды несёт ответственность за весьисходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.
9. Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
Если вы будете выполнять интеграцию разрабатываемой системы достаточно часто, вы сможете избежать большей части связанных с этим проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
Разработчики, по-возможности, должны интегрировать и выпускать свой код каждые несколько часов. В любом случае никогда нельзя держать изменения дольше одного дня. Частая интеграция позволяет избежать отчуждения и фрагментирования в разработке, когда разработчики не могут общаться в смысле обмена идеями или повторного использования кода. Каждый должен работать с самой последней версией.
Каждая пара разработчиков должна отдавать свой код как только для этого появляется разумная возможность. Это может быть когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция - это деятельность вида "заплати сейчас или заплати больше позднее". Поэтому интегрируя изменения ежедневно маленькими порциями вы не окажетесь перед необходимостью тратить неделю чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы.
10. 40-часовая неделя (40-hour week). Как правило, над проектом работают не более 40 часов в неделю. Нельзя увеливать рабочую неделю за счет сверхурочных работ. Этот принцип дает социальную защищенность команды.
11. Локальный заказчик (on-site customer). В группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков. В данном случае, заказчик – конечный пользователь программного продукта, эксперт предметной области, член команды разработчиков, а не просто помощник.
12. Стандарты кодирования (coding standards). Должны выдерживаться правила (не важно какие), обеспечивающие одинаковое представление программного кода во всех частях программной системы (например, форматирование кода, именование классов, переменных, констант, стиль комментариев). Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнеров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного кода, — вся команда работает унифицировано, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объемным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта.