|
fib(n-1)
+ 1;
}
Вторая ед иница в сумме – на самом д еле fib(n-2):
int fib(int n) {
if (n == 0) return 0;
if (n <= 2) return 1;
return fib(n-1) +
fib(n-2)
;
}
Теперь окончательно чистим код . Та же самая структура д олжна
работать д ля fib(2), поэтому мы можем преобразовать второй условный
оператор:
int fib(int n) {
if (n == 0) return 0;
if
(n == 1)
return 1;
return fib(n-1) + fib(n-2);
}
Это и есть функция вычисления по след овательно сти Фибоначчи,
целиком и полно стью разработанная в рамках метод ики TDD.
Послесловие
Мартин Фаулер (Martin Fowler)
Когд а рассказываешь о разработке, о снованной на тестировании,
сложнее всего перед ать то психическое со стояние, в котором
наход ишься, работая в стиле TDD. Я помню, как в ход е проекта C3 мы с
Ральфом Битти (Ralph Beattie) работали над реализацией сложного
набора условий выплаты. Ральф сформулировал набор соответствующих
тестов, по сле чего мы приступили к реализации этих тестов од ного за
д ругим. Процесс был равномерным и неторопливым, из-за этого
казало сь, что мы работаем мед ленно. Од нако, взглянув назад на
прод еланную работу, можно было понять, что, несмотря на кажущуюся
неторопливо сть, мы работали очень д аже быстро.
Несмотря на множество появившихся в по след нее время мощных
инструментов, программирование по-прежнему о стается сложной
работой. Я часто ощущаю себя в ситуации, когд а мне кажется, что я
жонглирую шариками и мне приход ится след ить сразу за несколькими
шариками в возд ухе: малейшая потеря внимания, и все сыпется на пол.
Метод ика TDD позволяет избавиться от этого ощущения.
Когд а вы работаете в стиле TDD, в возд ухе по стоянно наход ится
лишь од ин шарик. Вы можете сконцентрироваться на нем, а значит,
хорошо справиться со своей работой. Когд а я д обавляю в программу
новую функционально сть, я не д умаю о том, какой д изайн д олжен быть
реализован в д анной функции. Я про сто пытаюсь д обиться успешного
выполнения тестов самым про стым из д о ступных мне спо собов. Когд а я
переключаюсь в режим рефакторинга, я не беспокоюсь о д обавлении в
программу новых функций, я д умаю только о правильном д изайне. На
кажд ом из этих этапов я концентрируюсь на ед инственной зад аче,
благод аря этому мое внимание не распыляется.
Добавление новой функционально сти при помощи тестов и
рефакторинг
–
это
д ве
монологические
разновид но сти
программирования. Совсем нед авно я открыл еще од ну разновид но сть:
копирование шаблона. Я занимался разработкой сценария на языке Ruby,
извлекающего информацию из базы д анных. Я начал с созд ания класса,
являющего ся оболочкой таблицы базы д анных, а затем сказал себе, что,
раз я только что закончил книгу о шаблонах работы с базами д анных, я
д олжен использовать шаблон. Примеры программ в книге были
написаны на Java, поэтому нужный мне код легко можно было перенести
на Ruby. Когд а я программировал, я не д умал о решении проблемы, я
д умал лишь о том, как лучше всего ад аптировать шаблон д ля условий, в
рамках которых я работал.
Копирование шаблонов само по себе не является хорошим
программированием, – я всегд а под черкиваю этот факт, когд а говорю о
шаблонах. Любой шаблон – это полуфабрикат, – вы д олжны
ад аптировать его д ля условий своего проекта. Од нако чтобы сд елать
это, лучше всего вначале, о собо не зад умываясь, скопировать шаблон, а
затем, во спользовавшись смесью рефакторинга и TDD, выполнить
ад аптацию. В этом случае в процессе копирования шаблона вы также
концентрируетесь только на од ной вещи – на шаблоне.
Сообщество XP активно работает над д обавлением шаблонов в
общую картину. Со всей очевид но стью можно сказать, что сообщество
XP любит шаблоны. В конце концов, межд у множеством приверженцев
XP и множеством приверженцев шаблонов существует значительное
пересечение: Уорд и Кент являются лид ерами обоих направлений.
Наверное, копирование шаблона – это третий монологический режим
программирования наряд у с разработкой в стиле «сначала тесты»
и рефакторингом. Как и первые д ва режима, копирование шаблона –
опасная штука, если ее использовать отд ельно от д вух д ругих режимов.
Все три вид а программирования проявляют свою мощь только тогд а,
когд а используются совместно д руг с д ругом.
Если вы хотите сд елать некоторый процесс эффективным, вы
д олжны ид ентифицировать о сновные д ействия, из которых со стоит
процесс, а затем д обиться, чтобы в кажд ый момент времени внимание
концентрировало сь только на од ном таком д ействии. Примером такого
под ход а является сборочная линия, гд е кажд ый рабочий выполняет
только од ну из множества необход имых процед ур. Внимание кажд ого
рабочего сконцентрировано только на од ном д ействии. Метод ика
разработки через тестирование (TDD) под разумевает разд еление
процесса программирования на элементарные режимы, од нако при этом
она избавляет от монотонно сти, позволяя быстро переключаться межд у
этими режимами. Комбинация монологических режимов и переключения
межд у ними обеспечивает д олжную концентрацию внимания, снижает
стресс и избавляет от монотонно сти сборочной линии.
Я признаю, что все эти мысли несколько сыроваты. Когд а я пишу
это, я по-прежнему не уверен в том, о чем рассказываю. Я знаю, что буд у
обд умывать все эти ид еи еще в течение нескольких, а может быть, и
многих месяцев. Од нако я полагаю, что эти ид еи д олжны вам
понравиться. Прежд е всего, они стимулируют размышления о более
крупной картине, в которую вписывается разработка через тестирование.
Мы еще не вид им эту картину д о статочно четко, од нако мне кажется,
что она по степенно становится все яснее и яснее.
Do'stlaringiz bilan baham: |
