Экстремальное программирование. Разработка через тестирование

Как TDD способствует созданию инфраструктур?
Инфраструктура (framework) – набор обобщенного код а, который
можно использовать в качестве базы при разработке разнообразных

---

приклад ных программ. На самом д еле TDD является неплохим
инструментом разработки инфраструктур. Парад окс: если вы перестаете
д умать о буд ущем вашего код а, вы д елаете код значительно более
ад аптируемым д ля повторного использования в буд ущем.
Очень многие умные книги говорят об обратном: «код ируйте д ля
сегод няшнего д ня, но проектируйте д ля завтрашнего» (code for today,
design for tomorrow). Похоже, что TDD переворачивает этот совет с ног
на голову: «код ируйте д ля завтрашнего д ня, проектируйте д ля
сегод няшнего» (code for tomorrow, design for today). Вот что происход ит
на практике:
• В программу д обавляется первая функционально сть. Она
реализуется про сто и прямолинейно, поэтому реализация выполняется
быстро и с наименьшим количеством д ефектов.
• В программу д обавляется вторая функционально сть, которая
является 
вариацией 
первой. 
Дублирование 
межд у 
д вумя
функционально стями объед иняется и размещается в од ном месте.
Различия оказываются в разных местах (как правило, в разных метод ах
или в разных классах).
• В программу д обавляется третья функционально сть, которая
является вариацией первых д вух. Уже имеющаяся общая логика, как
правило, может использоваться в том вид е, в котором она уже
присутствует 
в 
программе, 
возможно, 
потребуется 
внести
незначительные изменения. Отличающаяся логика д олжна располагаться
в отд ельном месте – в д ругом метод е или в д ругом классе.
В процессе разработки мы по степенно привод им код в соответствие
с 
принципом 
открыто сти/закрыто сти 
(Open/Closed 
Principle
[28]
),
утвержд ающим, что объекты д олжны быть открыты д ля использования,
но закрыты д ля мод ификации. Самое интересное, что при использовании
TDD этот принцип выполняется именно д ля тех вариаций, с которыми
д ействительно приход ится иметь д ело на практике. То есть TDD
позволяет формировать инфраструктуры, уд обные д ля пред ставления
таких вариаций, с необход имо стью реализации которых программист
сталкивается на практике. Од нако эти инфраструктуры могут оказаться
неэффективными в случае, если потребуется реализовать вариацию,
которая ред ко встречается в реально сти (или которая не была еще
реализована ранее).
Что 
же 
произойд ет, 
если 
необход имо сть 
реализации
непред вид енной вариации возникнет спустя три год а по сле разработки
инфраструктуры? Дизайн быстро эволюционирует так, чтобы сд елать

---

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