ВУЗ:
Составители:
Рубрика:
75
5. Тестирование (Testing) – непрерывное написание тестов для мо-
дулей, которые должны выполняться безупречно; заказчики пишут тесты
для демонстрации законченности функций. «Тестируй, а затем кодируй»
означает, что входным критерием для написания кода является «отказав-
ший» тестовый вариант.
6. Реорганизация (Refactoring) – система реструктурируется, но её
поведение не изменяется; цель – устранить дублирование, улучшить
взаимодействие, упростить систему или добавить в неё гибкость.
7. Парное программирование (Pair programming) – весь код пишется
двумя программистами, работающими на одном компьютере.
8. Коллективное владение кодом (Collective ownership) – любой
разработчик может улучшать любой код системы в любое время.
9. Непрерывная интеграция (Continuous integration) – система ин-
тегрируется и строится много раз в день по мере завершения каждой зада-
чи. Непрерывное регрессионное тестирование, т.е. повторение предыду-
щих тестов гарантирует, что изменения требований не приведут к регрес-
су функциональности.
10. 40-часовая неделя (40-hour week) – как правило, работают не бо-
лее 40 часов в неделю. Нельзя удваивать рабочую неделю за счёт сверх-
урочных работ.
11. Локальный заказчик (On-site customer) – в группе всё время дол-
жен находиться представитель заказчика, действительно готовый отвечать
на вопросы разработчиков.
12. Стандарты кодирования (Coding standards) – должны выдержи-
ваться правила, обеспечивающие одинаковое представление программно-
го кода во всех частях программной системы.
Игра планирования и частая смена версий зависят от заказчика,
обеспечивающего набор «историй» (коротких описаний), характеризую-
щих работу, которая будет выполняться для каждой версии системы. Вер-
сии генерируются каждые две недели, поэтому разработчики и заказчик
должны прийти к соглашению о том, какие истории будут осуществлены
в пределах двух недель. Полную функциональность, требуемую заказчи-
ку, характеризует пул историй; но для следующей двухнедельной итера-
ции из пула выбирается подмножество историй, наиболее важное для за-
казчика. В любое время в пул могут быть добавлены новые истории, та-
ким образом, требования могут быстро изменяться. Однако процессы
двухнедельной генерации основаны на наиболее важных функциях, вхо-
дящих в текущий пул, следовательно, изменчивость управляется. Локаль-
ный заказчик обеспечивает поддержку этого стиля итерационной разра-
ботки.
«Метафора» обеспечивает глобальное «видение» проекта. Она могла
бы рассматриваться как высокоуровневая архитектура, но ХР подчёркива-
ет желательность проектирования при минимизации проектной докумен-
Страницы
- « первая
- ‹ предыдущая
- …
- 73
- 74
- 75
- 76
- 77
- …
- следующая ›
- последняя »
