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

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

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

Что является самым простым?

Таким образом, лучшим является самый простой дизайн, который обеспечивает срабатывание всех тестовых случаев. Чтобы сделать это определение эффективным, необходимо объяснить, что именно мы подразумеваем, когда говорим самый простой.

Может быть, самый простой дизайн – это дизайн с наименьшим количеством классов? Но если в системе мало классов, значит используемые объекты становятся настолько большими, что их неудобно использовать.

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

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

1. Система (как ее код, так и соответствующие тесты) должна выражать собой все, что вы хотите сообщить о ней всем остальным участникам проекта.

2. Система не должна содержать дублирующегося кода (1 и 2 пункты вместе составляют собой правило Once and Only Once).

3. Система должна состоять из наименьшего возможного количества классов.

4. Система должна содержать в себе наименьшее возможное количество методов.

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

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

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

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

Еще один способ взглянуть на этот процесс – это провести аналогию со стиранием. У вас есть система, для которой срабатывают все тестовые случаи. Вы удаляете из нее все, что не имеет определенной цели – либо коммуникационной цели, либо вычислительной цели. То, что остается, – это самый простой дизайн, который, скорее всего, сработает.

Как это может работать?

Традиционная стратегия сокращения с течением времени затрат на разработку программного обеспечения заключается в том, чтобы снизить вероятность переработки и затраты, связанные с переработкой. ХР предлагает действовать с точностью до наоборот. Вместо того чтобы снижать частоту переработки, ХР наслаждается переработкой. День без переработки – это день без солнечного света. Но как это может обходиться дешевле?