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

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

2. Инкрементная поставка продукта. Когда предстоит сменить целиком существующую систему, начинайте процесс с изменения нескольких функций и постепенно замените всю систему.

3. Контракт с оговоренным объемом работ. Контракт на разработку программного обеспечения включает в себя время, затраты и качество системы. Однако точные объемы этой системы надо оговаривать в процессе работы. Заключив с заказчиком серию небольших контрактов можно значительно снизить риски.

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

5. Постоянство. Команда разработчиков должна работать с одном и том же составе на протяжении нескольких проектов.

6. “услужка и утряска”. Если команда становится более продуктивной не стоит увеличивать ей нагрузку. Оставьте объем работ прежним, но выделите свободных членов этой команды с тем, чтобы они создавали свои собственные новые команды.

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

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

9. Общий код. Любой член команды может в любой момент изменить любую часть системы и внести изменения.

10. Единая база программного кода. Существует только одна официальная версия разрабатываемой системы. Если вам понадобилось создать для чего-то новую ветку (на пример опробовать другой метод или алгоритм, то данную ветку оставляйте на несколько часов).

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

Концепция шаблонов проектирования

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

Любой паттерн – это не образец, с которого надо копировать ваш код, образец оформления кода, которому надо следовать. Это описание или образец для того, как решить задачу таким образом, чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные шаблоны зачастую показывают отношение и взаимодействие между классами или объектами из определения того, какие конечные классы и объекты приложения будут использоваться. Шаблоны проектирования независимы от применяемого языка программирования. В описании каждого шаблона нужно указывать:

1. Имя шаблона

2. Назначение шаблона и описание задачи, которую он призван решать

3. Способ решения поставленной задачи

4. Ограничение требований, которые необходимо принимать во внимание при решении задачи

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

Шаблоны могут помочь разработчику в следующем:

1. Многократно применять высококачественное решение для повторяющихся задач

2. Ввести общую терминологию для расширения взаимопонимания в пределах группы разработчиков

3. Поднять уровень, на котором проблема решается, и избежать нежелательного углубления в детали реализации уже на ранних этапах разработки

4. Оценить, что было создано именно то, что нужно или некоторое работоспособное решение

5. Ускорить профессиональное развитие всей как группы разработчиков в целом, так и отдельных членов в целом

6. Повысить модифицированность кода

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

8. Найти альтернативное решение для исключения громоздких иерархий наследования классов.

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