Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 76

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 70 71 72 73 74 75 < 76 > 77 78 79 80 .. 81 >> Следующая


• Test (тест) — автоматическая процедура, позволяющая убедиться в работоспособности кода. Нажмите на кнопку, и он будет выполнен. Ирония TDD состоит в том, что это вовсе не методика тестирования. Это методика анализа, методика проектирования, фактически методика структурирования всей деятельности, связанной с разработкой программного кода.

Как методика TDD связана с практиками экстремального программирования?

Некоторые из людей, просматривавших рукопись данной книги, были обеспокоены тем, что книга целиком и полностью посвящена TDD, в результате читатели могут подумать, что остальными практиками XP (eXtreme Programming) можно пренебречь. Например, если вы работаете в стиле TDD, должны ли вы при этом работать в паре? Далее я привожу перечень соображений относительно того, каким образом остальные практики XP улучшают эффективность TDD, и наоборот, каким образом TDD повышает эффективность использования других практик XP:

• Программирование в паре. Тесты, разрабатываемые в рамках TDD1 являются превосходным инструментом общения, когда вы программируете в паре. Зачастую, работая в паре партнеры не могут договориться — какую именно проблему они решают, несмотря на то что они работают с одним и тем же кодом. Это звучит бредово, однако подобное происходит постоянно, в особенности когда вы только осваиваете работу в паре. Именно этой проблемы удается избежать благодаря TDD. Существует и обратное влияние: когда вы работаете в паре, у вас есть помощник, который может взять на себя нагрузку в случае, если вы устали. Ритм TDD может исчерпать ваши силы, и тогда вы будете вынуждены программировать несмотря на то, что вы устали. Однако если вы работаете в паре, ваш партнер готов взять у вас клавиатуру и тем самым предоставить вам возможность немного расслабиться.

• Работа на свежую голову. XP рекомендует работать тогда, когда вы полны . сил, и останавливать работу тогда, когда вы устали. Если вы не можете заставить следующий тест сработать или заставить работать те два теста одновременно, значит, настало время прерваться. Однажды мы с дядей Бобом Мартином (Bob Martin)1 работали над алгоритмом разбиения линии и нам никак не удавалось заставить его работать. Несколько минут мы безуспешно бились над кодом, однако нам стало очевидно, что прогресса нет, поэтому мы просто остановили работу.

• Частая интеграция. Тесты — это великолепный ресурс, который позволяет вам выполнять интеграцию значительно чаще. Вы добились срабатывания очередного теста, удалили дублирование, значит, вы можете интегрировать код. Этот цикл может повторяться в течение 15-30 минут. Возможность частой интеграции позволяет более многочисленным командам разработчиков иметь дело с одной и той же базой исходного кода. Как сказал Билл Уэйк (Bill Wake): «проблема п2 не является проблемой, если п всегда равно 1».

• Простой дизайн. В рамках TDD вы пишете только тот код, который необ-, ходим для срабатывания тестов, вы удаляете из него любое дублирование,

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

• Рефакторинг. Удаление дублирования — это основная цель рефакторинга. Тесты дают вам уверенность в том, что поведение системы не изменится даже в случае, если вы выполняете достаточно крупномасштабные рефакторинги. Чем выше ваша уверенность, тем более агрессивно вы выполняете

1 Боб Мартин (Bob Martin) — известный деятель движения Agile Development, которого часто с уважением называют дядей. — Примеч. перев.

рефакторинг. Рефакторинг продлевает жизнь вашей системе. Благодаря рефакторингу вы упрощаете дальнейшую разработку тестов.

• Частые выпуски версий. Если тесты TDD действительно улучшают MTBF вашей системы (в этом вы можете убедиться сами), значит, вы можете чаще внедрять разрабатываемый код в реальные производственные условия и при этом не наносить ущерба вашим заказчикам. Гарет Ривс (Gareth Reeves) приводит аналогию с куплей-продажей ценных бумаг на бирже в течение дня. Если вы занимаетесь краткосрочной спекуляцией ценными бумагами, в конце торгового дня вы должны продать все имеющиеся у вас ценные бумаги, так как вы не хотите принимать риск, связанный с сохранением некоторых ценных бумаг до следующего торгового дня, — этот риск вам не подконтролен. Разрабатывая систему, вы хотите, чтобы вносимые вами изменения как можно быстрее были опробованы в реальных производственных условиях, так как не хотите тратить время на разработку кода, в полезности которого не уверены.

Нерешенные проблемы TDD

Дарач Эннис (Darach Ennis) бросил вызов поклонникам TDD, размышляющим о возможностях расширения области применения TDD. Он сказал:

Множество различных организаций сталкивается с многочисленными проблемами TDD, и эти проблемы никак не затронуты в книге. Возможно, эти проблемы вообще никак не решить в рамках TDD. Вот некоторые из них:
Предыдущая << 1 .. 70 71 72 73 74 75 < 76 > 77 78 79 80 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100