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

 

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

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

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


мени смотрит на красную полосу. Если я работаю в стиле TDD на уровне программиста, я:

• немедленно получаю зеленую полосу;

• упрощаю внутренний дизайн.

Как можно перейти к использованию TDD в середине работы над проектом?

У вас есть некоторый объем кода, про который можно сказать, что он корректно работает в большей или меньшей степени. Теперь вы хотите разрабатывать весь новый код в рамках концепции TDD. Что делать?

О проблеме перехода на использование TDD в середине работы над проектом можно написать целую книгу (или даже несколько книг). В данном небольшом разделе я очень поверхностно затрону несколько связанных с этим вопросов.

Самая большая проблема заключается в том, что код, изначально написанный без учета тестов, как правило, сложен в тестировании. Интерфейсы и взаимосвязи между объектами не достаточно хорошо спроектированы, поэтому вам сложно изолировать некоторый кусок логики, запустить его и проверить результаты.

«Надо это исправить» — скажете вы. Да, однако любой рефакторинг (без применения средств автоматизации), скорее всего, приведет к возникновению ошибок, и эти ошибки сложно будет обнаружить, так как у вас нет тестов. Проблема яйца и курицы. Змея кусает сама себя за хвост. Замкнутый цикл саморазрушения. Что же делать?

Прежде всего, скажу, чего делать не надо: не надо писать тесты для всего кода и выполнять рефакторинг всего кода. Для этого может потребоваться несколько месяцев, в течение которых у вас не будет времени добавить в систему новой функциональности. Если вы тратите имеющиеся у вас деньги и при этом не зарабатываете новых, долго вы так не протянете.

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

Во-вторых, мы должны разорвать замкнутый круг между тестами и рефакто-рингом. Мы можем использовать в качестве обратной связи не только тесты, но и другие способы, например чрезвычайно осторожная работа в паре с партнером. Мы можем использовать обратную связь более высокого уровня, например тесты на уровне всей системы. Мы знаем, что такие тесты не являются адекватными, однако они прибавляют нам уверенности. Благодаря такой обратной связи мы можем сделать части кода, нуждающиеся в изменении, более удобными для внесения изменений. ,

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

Для кого предназначена методика TDD?

Каждая практика программирования явно или не явно базируется на системе ценностей. TDD — не исключение. Если вам нравится лепить вместе куски кода, которые более-менее работают, и вы счастливы думать о том, что вам не придется возвращаться к полученному в результате этого коду в дальнейшем, значит, TDD — не для вас. Методика TDD базируется на очаровательно-наивном предположении программиста о том, что чем красивее код, тем вероятнее успех. TDD помогает вам обращать внимание на правильные вопросы в подходящие для этого моменты времени. Благодаря этому вы можете делать дизайн чище и модифицировать его по мере того, как перед вами встают новые обстоятельства.

Я сказал, что предположение наивное, однако, скорее всего, я преувеличил. На самом деле наивно предполагать, что чистый код — это все, что необходимо для успеха. Мне кажется, что хорошее проектирование — это лишь 20 % успеха. Безусловно, если проектирование будет плохим, вы можете быть на 100 % уверены в том, что проект провалится. Однако приемлемый дизайн сможет обеспечить успех проекта только в случае, если остальные 80 % будут там, где им полагается быть.

С этой точки зрения TDD — это чрезвычайно мощный инструмент. Если сравнивать со средним уровнем индустрии разработки программного обеспечения, методика TDD позволяет вам писать код, содержащий значительно меньше дефектов и формировать значительно более чистый дизайн. Те, кто стремится к изяществу, могут найти в TDD средство для достижения цели.

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