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

17. Ретроспектива денежного примера 
Давайте 
еще 
раз 
окинем 
взгляд ом 
пример 
реализации
мультивалютных вычислений и попробуем оценить использованный
нами под ход и полученные результаты. Вот несколько тезисов, которых
хотело сь бы ко снуться:
 Что дальше?
Как опред елить д альнейшее направление разработки?
 Метафора
. Впечатляющий эффект, который метафора оказывает на
структуру д изайна.
Использование JUnit
. Как часто мы запускали тесты и как мы
использовали JUnit?
 Метрики кода
. Численные характеристики получившего ся код а.
Процесс
. Мы говорим: «красный – зеленый – рефакторинг». Как
много усилий приклад ывается на кажд ом из этих этапов?
Качество тестов
. Каким образом характеристики тестов TDD
соотно сятся с характеристиками обычных метод ик тестирования?
Что дальше?
Можно ли считать код завершенным? Нет. Метод ы Sum.plus() и
Money.plus() во многом д ублируют д руг д руга. Если мы преобразуем
интерфейс Expression в класс (не совсем обычное преобразование – чаще
классы 
становятся 
интерфейсами), 
мы 
получим 
возможно сть
переместить общий код в ед иный общий метод .
На самом д еле мне сложно пред ставить себе код , который
полно стью завершен. Метод ику TDD можно использовать как спо соб
приближения к ид еалу, од нако это буд ет не самое эффективное ее
использование. Если вы имеете д ело с крупной системой, тогд а части
системы, с которыми вы работаете кажд ый д ень, д олжны быть
тщательно «вылизаны». Иными словами, д изайн д олжен быть чистым и
понятным, а код д олжен быть хорошо протестированным. В этом случае
вы изо д ня в д ень сможете вно сить в систему необход имые изменения,
не теряя при этом уверенно сти в работо спо собно сти код а. Од нако на
периферии системы, гд е располагаются части, к которым вы
обращаетесь отно сительно ред ко, количество тестов может быть
меньше, а д изайн – урод ливее.

---

Когд а я завершаю решение всех очевид ных зад ач, я люблю
запускать инструмент проверки оформления код а (например, SmallLint
д ля Smalltalk). Многие полученные в результате этого пред ложения мне
и без того известны. Со многими пред ложениями я не согласен. Од нако
автоматизированный инструмент проверки код а ни о чем не забывает,
поэтому иногд а он обнаруживает то, что было упущено мною из вид у.
Еще од ин полезный вопро с: «Какие д ополнительные тесты
необход имо написать д ля системы?» Иногд а кажется, что некоторый
тест д олжен потерпеть неуд ачу, од нако, д обавив его в тестовый набор,
вы обнаруживаете, что он работает. В этом случае необход имо
опред елить, почему так происход ит. Иногд а тест, который не д олжен
работать, д ействительно не работает, и вы д обавляете его в набор, как
признак известного вам ограничения разрабатываемой системы или как
напоминание о работе, которую необход имо выполнить позд нее.
Наконец, когд а список зад ач пуст, неплохо еще раз проверить
д изайн. Уд овлетворяет ли д анная реализация всем пред ъявляемым
требованиям? Существует ли д ублирование, которое сложно устранить
при использовании д анного д изайна? (Сохранившееся д ублирование –
признак нереализованного д изайна.)