|
Как методика TDD связана с практиками экстремального
программирования?
Некоторые из рецензетов д анной книги, были обеспокоены тем, что
книга целиком и полно стью по священа TDD, в результате читатели
могут под умать, что о стальными практиками XP (eXtreme Programming
– экстремальное программирование) можно пренебречь. Например, если
вы работаете в стиле TDD, д олжны ли вы при этом работать в паре?
Далее я привожу перечень соображений отно сительно того, как
о стальные практики XP улучшают эффективно сть TDD и, наоборот, как
TDD повышает эффективно сть использования д ругих практик XP.
Программирование в паре. Тесты, разрабатываемые в рамках TDD,
являются
прево сход ным
инструментом
общения,
когд а
вы
программируете в паре. Зачастую, работая в паре, партнеры не могут
д оговориться – какую именно проблему они решают, несмотря на то
что работают с од ним и тем же код ом. Это звучит бред ово, од нако
под обное происход ит по стоянно, в о собенно сти когд а вы только
о сваиваете работу в паре. Именно этой проблемы уд ается избежать
благод аря TDD. Существует и обратное влияние: когд а вы работаете в
паре, у вас есть помощник, который может взять на себя нагрузку в
случае, если вы устали. Ритм TDD может исчерпать ваши силы, и тогд а
вы буд ете вынужд ены программировать, несмотря на устало сть. Од нако
если вы работаете в паре, ваш партнер готов взять у вас клавиатуру и
тем самым д ать вам возможно сть немного расслабиться.
Работа на свежую голову. XP рекоменд ует работать, когд а вы полны
сил, и о станавливать работу, когд а вы устали. Если вы не можете
заставить след ующий тест сработать или заставить работать те д ва
теста од новременно, значит, настало время прерваться. Од нажд ы мы с
д яд ей Бобом Мартином (Bob Martin
[31]
) работали над алгоритмом
разбиения линии, и нам никак не уд авало сь заставить его работать.
Несколько минут мы безуспешно бились над код ом, од нако нам стало
очевид но, что прогресса нет, поэтому мы про сто о становили работу.
Частая интеграция. Тесты – это великолепный ресурс, который
позволяет выполнять интеграцию значительно чаще. Вы д обились
успешного выполнения очеред ного теста, избавились от д ублирования,
значит, вы можете интегрировать код . Этот цикл может повторяться
кажд ые 15–30 минут. Возможно сть частой интеграции позволяет более
многочисленным команд ам разработчиков иметь д ело с од ной и той же
базой исход ного код а. Как сказал Билл Уэйк (Bill Wake): «Проблема
n2
не
является проблемой, если
n
всегд а равно 1».
Про стой д изайн. В рамках TDD вы пишете только тот код , который
необход им д ля успешного выполнения тестов, вы уд аляете из него
любое д ублирование, значит, вы автоматически получаете код , который
ид еально ад аптирован к текущим требованиям и под готовлен к любым
буд ущим пожеланиям. Общая д октрина требует, чтобы д изайна было
д о статочно д ля получения ид еальной архитектуры д ля текущей
системы. Эта д октрина также облегчает разработку тестов.
Рефакторинг. Устранение д ублирования – это о сновная цель
рефакторинга. Тесты д ают вам уверенно сть в том, что повед ение
системы не изменится д аже в случае, если в ход е рефакторинга вы
вно сите д о статочно крупномасштабные изменения. Чем выше ваша
уверенно сть, тем более агрессивно вы выполняете рефакторинг.
Рефакторинг прод левает жизнь вашей системе. Благод аря рефакторингу
вы упрощаете д альнейшую разработку тестов.
Частые выпуски версий. Если тесты TDD д ействительно улучшают
MTBF вашей системы (в этом вы можете убед иться сами), значит, вы
можете
чаще
внед рять
разрабатываемый
код
в
реальные
производ ственные условия и при этом не нано сить ущерба вашим
заказчикам. Гарет Ривс (Gareth Reeves) привод ит аналогию с куплей-
прод ажей ценных бумаг на бирже в течение д ня. Если вы занимаетесь
кратко срочной спекуляцией ценными бумагами, в конце торгового д ня
вы д олжны прод ать все имеющиеся у вас ценные бумаги, так как вы не
хотите принимать риск, связанный с сохранением некоторых ценных
бумаг д о след ующего торгового д ня, – этот риск вам не под контролен.
Разрабатывая систему, вы хотите, чтобы вно симые вами изменения как
можно быстрее были опробованы в реальных производ ственных
условиях, так как не хотите тратить время на разработку код а, в
полезно сти которого не уверены.
Do'stlaringiz bilan baham: |
