Книга: Экстремальное программирование. Разработка через тестирование
Назад: Приложение II Фибоначчи
Дальше: Примечания

Послесловие

Мартин Фаулер (Martin Fowler)

 

Когда рассказываешь о разработке, основанной на тестировании, сложнее всего передать то психическое состояние, в котором находишься, работая в стиле TDD. Я помню, как в ходе проекта C3 мы с Ральфом Битти (Ralph Beattie) работали над реализацией сложного набора условий выплаты. Ральф сформулировал набор соответствующих тестов, после чего мы приступили к реализации этих тестов одного за другим. Процесс был равномерным и неторопливым, из-за этого казалось, что мы работаем медленно. Однако, взглянув назад на проделанную работу, можно было понять, что, несмотря на кажущуюся неторопливость, мы работали очень даже быстро.
Несмотря на множество появившихся в последнее время мощных инструментов, программирование по-прежнему остается сложной работой. Я часто ощущаю себя в ситуации, когда мне кажется, что я жонглирую шариками и мне приходится следить сразу за несколькими шариками в воздухе: малейшая потеря внимания, и все сыпется на пол. Методика TDD позволяет избавиться от этого ощущения.
Когда вы работаете в стиле TDD, в воздухе постоянно находится лишь один шарик. Вы можете сконцентрироваться на нем, а значит, хорошо справиться со своей работой. Когда я добавляю в программу новую функциональность, я не думаю о том, какой дизайн должен быть реализован в данной функции. Я просто пытаюсь добиться успешного выполнения тестов самым простым из доступных мне способов. Когда я переключаюсь в режим рефакторинга, я не беспокоюсь о добавлении в программу новых функций, я думаю только о правильном дизайне. На каждом из этих этапов я концентрируюсь на единственной задаче, благодаря этому мое внимание не распыляется.
Добавление новой функциональности при помощи тестов и рефакторинг – это две монологические разновидности программирования. Совсем недавно я открыл еще одну разновидность: копирование шаблона. Я занимался разработкой сценария на языке Ruby, извлекающего информацию из базы данных. Я начал с создания класса, являющегося оболочкой таблицы базы данных, а затем сказал себе, что, раз я только что закончил книгу о шаблонах работы с базами данных, я должен использовать шаблон. Примеры программ в книге были написаны на Java, поэтому нужный мне код легко можно было перенести на Ruby. Когда я программировал, я не думал о решении проблемы, я думал лишь о том, как лучше всего адаптировать шаблон для условий, в рамках которых я работал.
Копирование шаблонов само по себе не является хорошим программированием, – я всегда подчеркиваю этот факт, когда говорю о шаблонах. Любой шаблон – это полуфабрикат, – вы должны адаптировать его для условий своего проекта. Однако чтобы сделать это, лучше всего вначале, особо не задумываясь, скопировать шаблон, а затем, воспользовавшись смесью рефакторинга и TDD, выполнить адаптацию. В этом случае в процессе копирования шаблона вы также концентрируетесь только на одной вещи – на шаблоне.
Сообщество XP активно работает над добавлением шаблонов в общую картину. Со всей очевидностью можно сказать, что сообщество XP любит шаблоны. В конце концов, между множеством приверженцев XP и множеством приверженцев шаблонов существует значительное пересечение: Уорд и Кент являются лидерами обоих направлений. Наверное, копирование шаблона – это третий монологический режим программирования наряду с разработкой в стиле «сначала тесты» и рефакторингом. Как и первые два режима, копирование шаблона – опасная штука, если ее использовать отдельно от двух других режимов. Все три вида программирования проявляют свою мощь только тогда, когда используются совместно друг с другом.
Если вы хотите сделать некоторый процесс эффективным, вы должны идентифицировать основные действия, из которых состоит процесс, а затем добиться, чтобы в каждый момент времени внимание концентрировалось только на одном таком действии. Примером такого подхода является сборочная линия, где каждый рабочий выполняет только одну из множества необходимых процедур. Внимание каждого рабочего сконцентрировано только на одном действии. Методика разработки через тестирование (TDD) подразумевает разделение процесса программирования на элементарные режимы, однако при этом она избавляет от монотонности, позволяя быстро переключаться между этими режимами. Комбинация монологических режимов и переключения между ними обеспечивает должную концентрацию внимания, снижает стресс и избавляет от монотонности сборочной линии.
Я признаю, что все эти мысли несколько сыроваты. Когда я пишу это, я по-прежнему не уверен в том, о чем рассказываю. Я знаю, что буду обдумывать все эти идеи еще в течение нескольких, а может быть, и многих месяцев. Однако я полагаю, что эти идеи должны вам понравиться. Прежде всего, они стимулируют размышления о более крупной картине, в которую вписывается разработка через тестирование. Мы еще не видим эту картину достаточно четко, однако мне кажется, что она постепенно становится все яснее и яснее.

notes

Назад: Приложение II Фибоначчи
Дальше: Примечания