Читаем Экстремальное программирование: Разработка через тестирование полностью

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

Параметр метода в параметр конструктора (Method Parameter to Constructor Parameter)

Как переместить параметр из метода или методов в конструктор?

Как

1. Добавьте параметр в конструктор.

2. Добавьте в класс переменную экземпляра с тем же именем, что и параметр.

3. Установите значение переменной в конструкторе.

4. Одну за другой преобразуйте ссылки parameter в ссылки this.parameter.

5. Когда в коде не останется ни одной ссылки на параметр, удалите параметр из метода.

6. После этого удалите ненужный теперь префикс this.

7. Присвойте переменной подходящее имя.

Зачем

Если вы передаете один и тот же параметр нескольким разным методам одного и того же объекта, вы можете упростить API, передав параметр только один раз (устранив дублирование). Напротив, если вы обнаружили, что некоторая переменная экземпляра используется только в одном методе объекта, вы можете выполнить обратный рефакторинг.

27 Fowler, Martin. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, 1999. Русское издание: Фаулер. М. Рефакторинг: улучшение существующего кода. СПб.: Символ-Плюс, 2003

<p>32. Развитие навыков TDD</p>

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

Насколько большими должны быть шаги?

В этом вопросе на самом деле скрыто два вопроса:

• Какой объем функциональности должен охватывать каждый тест?

• Как много промежуточных стадий должно быть преодолено в процессе каждого сеанса рефакторинга?

Вы можете писать тесты так, что каждый из них будет требовать добавления в функциональный код единственной строки и выполнения небольшого рефакторинга. Вы также можете писать тесты так, что каждый из них будет требовать добавления в функциональный код сотен строк, при этом у вас будут уходить часы на рефакторинг. Какой из этих путей лучше?

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

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

Автоматизация существенно ускоряет процессы, связанные с рефакторингом. То, что раньше требовало выполнения 20 маленьких шагов вручную, теперь становится единственным пунктом в меню. Количество изменений, выполняемых в ходе сеанса рефакторинга увеличивается на порядок, и это неизменно сказывается на качестве. Когда вы знаете, что в вашем распоряжении великолепный инструмент, вы становитесь более агрессивным при выполнении рефакторинга. Вы пытаетесь ставить больше экспериментов и смотреть, какой способ структурирования кода лучше.

На момент написания данной книги браузер рефакторинга Refactoring Browser for Smalltalk по-прежнему является наилучшим инструментом в этой категории. В настоящее время многие среды разработки для Java поддерживают развитые средства рефакторинга. Кроме того, поддержка рефакторинга появилась и в других языках и средах разработки.

Что не подлежит тестированию?

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

• условные операторы;

• циклы;

• операции;

• полиморфизм.

Перейти на страницу:

Все книги серии Библиотека программиста

Программист-фанатик
Программист-фанатик

В этой книге вы не найдете описания конкретных технологий, алгоритмов и языков программирования — ценность ее не в этом. Она представляет собой сборник практических советов и рекомендаций, касающихся ситуаций, с которыми порой сталкивается любой разработчик: отсутствие мотивации, выбор приоритетов, психология программирования, отношения с руководством и коллегами и многие другие. Подобные знания обычно приходят лишь в результате многолетнего опыта реальной работы. По большому счету перед вами — ярко и увлекательно написанное руководство, которое поможет быстро сделать карьеру в индустрии разработки ПО любому, кто поставил себе такую цель. Конечно, опытные программисты могут найти некоторые идеи автора достаточно очевидными, но и для таких найдутся темы, которые позволят пересмотреть устоявшиеся взгляды и выйти на новый уровень мастерства. Для тех же, кто только в самом начале своего пути как разработчика, чтение данной книги, несомненно, откроет широчайшие перспективы. Издательство выражает благодарность Шувалову А. В. и Курышеву А. И. за помощь в работе над книгой.

Чед Фаулер

Программирование, программы, базы данных / Программирование / Книги по IT

Похожие книги