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