Экстремальное программирование полностью

• организовать обратную связь для того, чтобы быстро воплощать наши новые открытия и выводы в дизайне системы;

• сжать цикл времени, в течение которого выполняется весь этот процесс, и сделать его как можно короче.

Принятые нами ранее принципы также хорошо воплощаются в стратегии дизайна.

• Небольшие изначальные инвестиции – прежде чем получить первую отдачу от дизайна, мы должны инвестировать в проектирование системы так мало, насколько это возможно.

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

• Постепенное изменение – стратегия дизайна будет работать благодаря постепенному изменению. Мы будем проектировать постепенно и понемногу. Никогда не наступит момент времени, когда можно будет сказать, что система полностью спроектирована. Дизайн системы будет постоянно меняться, однако при этом некоторые части системы, возможно, будут оставаться неизменными в течение некоторого времени.

• Путешествие налегке – стратегия проектирования не должна формировать какого-либо лишнего дизайна. Дизайн должен быть достаточным для того, чтобы решать наши текущие задачи (необходимость делать качественную работу), но не более того. Если нам придется постоянно все менять, мы должны иметь возможность начать с самого простого и постоянно пересматривать то, что у нас имеется на текущий момент.

ХР работает против многих программистских инстинктов. Мы, программисты, привыкли ожидать появления проблем. Если проблемы откладываются на более позднее время, мы счастливы. Если проблемы не появляются, мы не обращаем на это внимания. Поэтому наша стратегия проектирования должна увести нас в сторону от этих размышлений о будущем. К счастью, большинство разработчиков способно отучится от этой привычки брать неприятности взаймы (как про это говорила моя бабушка). К сожалению, чем вы умнее, тем сложнее вам отучиться от этого.

Еще один способ взглянуть на это предлагает заданный себе вопрос: Когда следует добавить еще дизайна? Общепринято отвечать на него, что вы должны думать о том, какие проблемы встанут перед вами завтра, и исходя из этого вы должны проектировать программу с расчетом на завтра (рис. 8).

Рис. 8. Если стоимость затрат стремительно растет с течением времени

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

Проблема, связанная с этой стратегией, – это неопределенность.

На практике:

• иногда завтра не наступает никогда (то есть возможность, которую вы спроектировали заранее, больше не интересует заказчика);

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

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

Я ничего не имею против изменений, вносимых заказчиком в план работ. Я также ничего не имею против того, чтобы со временем менять реализацию той или иной части системы в лучшую сторону. В этом случае картинку, изображенную на рис. 8, следует изменить. Мы должны проектировать систему так, чтобы сегодня решать те проблемы, которые стоят перед нами сегодня, и откладывать на завтра решение тех проблем, которые будут стоять перед нами завтра (рис. 9).

Рис. 9. Если с течением времени стоимость изменений остается невысокой

Это ведет нас к созданию следующей стратегии проектирования:

1. Вначале разрабатывается тест, благодаря чему у нас появляется возможность определить момент завершения работы. Для того чтобы просто написать тест, мы опять же должны выполнить некоторый объем проектирования: мы должны определить набор объектов, с которыми мы работаем, а также набор видимых методов для этих объектов.

2. Мы проектируем и реализуем только для того, чтобы обеспечить срабатывание тестов. Все только что разработанные нами тесты, а также все тесты, которые были разработаны ранее, должны сработать – это единственная цель, которую мы преследуем в процессе проектирования.

3. Повторяем.