Методология экстремального программирования (XP).

Экстремальное программирование (XP) правильнее было бы назвать экстремальное проектирование.

Само по себе экстремальное программирование ориентировано на небольшие группы до 10 чел. И соответственно размер проекта автоматически следует из размера группы, которая ограничена 10 людьми. Что важно для XP, что вся проектная группа должна быть размещена в одном помещении (одно из организационных требований, т.е. любые вопросы должны решаться за единицы минут, но не как там за часы, десятки часов и т.д.).

Игра в планирование – это когда заказчик и разработчики встречаются и пытаются в течении одной или нескольких бесед составить укрупненный план работы над проектом. При этом, что делает заказчик. Заказчик указывает объем работ, указывает приоритеты работ и указывает, что должно входит в отдельные выпускаемые версии и соответственно когда эти версии выпускаются.

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

Под простым здесь понимается правильный дизайн: выполняются все тесты, т.е. единственный критерий в экстремальном программировании, что у нас сделано все правильно – это выполняются все тесты. Тесты на самом деле накапливаются и их на самом деле очень много.

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

Для экстремального программирования он играет ключевую роль. Почему? Т.к. у нас постоянно меняются требования, т.к. постоянно выпускаются версии, то тестирование является единственным по сути методом обеспечения качества получаемого кода. И не только тестирование, а автоматическое тестирование, в крайнем случае автоматизированное тестирование, т.е. для любой возможности которая была у нас высказана в требованиях у нас формируется автоматически тест.

Рефакторинг это такое преобразование программы, при котором мы внешнее поведение программы не меняем, а внутренне устройство меняется.

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

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

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

Что подразумевает под собой непрерывная интеграция? Т.е. идея такая, в тот момент, когда сделано какое-то существенное изменение и разработчик это изменение помещает в репозиторий, в этот момент его часть кода интегрируется в общий проект.

Типы документов.