Я сказал, что предположение наивное, однако, скорее всего, я преувеличил. На самом деле наивно предполагать, что чистый код – это все, что необходимо для успеха. Мне кажется, что хорошее проектирование – это лишь 20 % успеха. Безусловно, если проектирование будет выполнено из рук вон плохо, вы можете быть на 100 % уверены, что проект провалится. Однако приемлемый дизайн сможет обеспечить успех проекта только в случае, если остальные 80 % будут там, где им полагается быть.
С этой точки зрения TDD – чрезвычайно мощный инструмент. Если сравнивать со средним уровнем индустрии разработки программного обеспечения, методика TDD позволяет писать код, содержащий значительно меньше дефектов, и формировать значительно более чистый дизайн. Те, кто стремится к изяществу, могут найти в TDD средство для достижения цели.
Методика TDD также подходит для тех, у кого формируется эмоциональная привязанность к коду. Когда я был молодым программистом, самым большим разочарованием для меня была ситуация, когда проект начинался с огромным воодушевлением, а затем, с течением времени, код становился все более отвратительным. Год спустя у меня, как правило, формировалось устойчивое желание уйти из проекта, чтобы никогда в жизни не иметь дела с этим гнусно пахнущим кодом. TDD позволяет с течением времени поддерживать уверенность в коде. По мере того как тестов становится все больше (а ваше мастерство тестирования улучшается), вы обретаете все большую уверенность в том, что система ведет себя именно так, как вам надо. По мере того как вы улучшаете дизайн, становится возможным все большее количество изменений. Моя цель заключается в том, чтобы через год работы мне было бы интереснее и приятнее работать над проектом, чем в самом начале проекта, и TDD помогает мне достигнуть этой цели.
Складывается впечатление, что разработка идет гладко только в случае, если тесты выполняются в определенном порядке. Тогда мы можем наблюдать классическую последовательность красный – зеленый – рефакторинг – красный – зеленый – рефакторинг. Вы можете попробовать взять те же самые тесты, но реализовать их в другом порядке, и у вас возникнет ощущение, что вы не сможете, как прежде, выполнять разработку маленькими шажками. Действительно ли одна последовательность тестов на порядок быстрее/проще в реализации, чем другая последовательность? Существуют ли какие-либо признаки тестов, которые могут подсказать, в какой последовательности их следует реализовать? Если методика TDD чувствительна к начальным условиям в малом масштабе, можно ли считать ее предсказуемой в более крупном масштабе? (Вот аналогия: отдельные потоки реки Миссисипи непредсказуемы, однако вы можете с уверенностью сказать, что через устье реки протекает приблизительно 2 000 000 кубических футов воды в секунду.)
Все мои технические публикации – это поиск фундаментальных правил, которые позволяют обычным людям действовать так, как действуют эксперты. Это связано с тем, как я сам осваиваю то или иное ремесло, – я нахожу эксперта, которому можно подражать, и постепенно выясняю, что, собственно, он делает. Определенно, я не предполагаю, что сформулированные мною правила должны использоваться автоматически, однако именно так и происходит.
Моя старшая дочь (привет, Бетани! Я же говорил тебе, что ты попадешь в мою книгу, – не беспокойся, это не слишком обременительно) в течение семи лет пыталась научиться быстро перемножать числа. Как я, так и моя жена, когда были маленькими, научились этому за значительно более короткий срок. В чем дело? Оказывается каждый раз, когда перед Бетани вставала задача умножить, например, 6 на 9, она складывала число 6 девять раз (или число 9 шесть раз). Таким образом, можно сказать, что Бетани вообще не умела умножать числа так, как это делают другие люди, однако при этом она необычайно быстро складывала числа.
Я обратил внимание на один важный эффект, который, я надеюсь, смогут принять во внимание и другие. Если на основе постоянно повторяющихся действий формулируются правила, дальнейшее применение этих правил становится неосознанным и автоматическим. Естественно, ведь это проще, чем обдумывать все «за» и все «против» того или иного действия с самого начала. Благодаря этому повышается скорость работы, и, если в дальнейшем вы сталкиваетесь с исключением или проблемой, которая не вписывается ни в какие правила, у вас появляется дополнительное время и энергия для того, чтобы в полной мере применить свои творческие способности.
Именно это произошло со мной, когда я писал книгу Smalltalk Best Practice Patterns. В какой-то момент я решил просто следовать правилам, описываемым в ней. В начале это несколько замедлило скорость моей работы – мне требовалось дополнительное время, чтобы вспомнить то или иное правило или написать новое. Однако по прошествии недели я заметил, что с моих пальцев почти мгновенно слетает код, над разработкой которого ранее мне приходилось некоторое время размышлять. Благодаря этому у меня появилось дополнительное время для анализа и важных размышлений о дизайне.
Существует еще одна связь между TDD и шаблонами: TDD является методом реализации дизайна, основанного на шаблонах. Предположим, что в определенном месте разрабатываемой системы мы хотим реализовать шаблон «Стратегия» (Strategy). Мы пишем тест для первого варианта и реализуем его, создав метод. После этого мы намеренно пишем тест для второго варианта, ожидая, что на стадии рефакторинга мы придем к шаблону «Стратегия» (Strategy). Мы с Робертом Мартином занимались исследованием подобного стиля TDD. Проблема состоит в том, что дизайн продолжает вас удивлять. Идеи, которые на первый взгляд кажутся вам вполне уместными, позже оказываются неправильными. Поэтому я не рекомендую целиком и полностью доверять своим предчувствиям относительно шаблонов. Лучше думайте о том, что, по-вашему, должна делать система, позвольте дизайну оформиться так, как это необходимо.
Приготовьтесь покинуть галактику. Предположите на секунду, что TDD помогает командам разработчиков создавать хорошо спроектированные, удобные в сопровождении системы с чрезвычайно низким уровнем дефектов. (Я не утверждаю, что это происходит на каждом шагу, я просто хочу, чтобы вы немножко помечтали.) Как такое может происходить?
Отчасти этот эффект связан с уменьшением количества дефектов. Чем раньше вы найдете и устраните дефект, тем дешевле это вам обойдется. Иногда разница в затратах огромна (спросите у «Марс-лендера»[30]). Снижение количества дефектов вызывает множество вторичных психологических и социальных эффектов. После того как я начал работать в стиле TDD, программирование стало для меня значительно менее нервным занятием. Когда я работаю в стиле TDD, мне не надо беспокоиться о множестве вещей. Вначале я могу заставить работать только один тест, потом – все остальные. Уровень стресса существенно снизился. Взаимоотношения с партнерами по команде стали более позитивными. Разработанный мною код перестал быть причиной сбоев, люди стали в большей степени рассчитывать на него. У заказчиков тоже повысилось настроение. Теперь выпуск очередной версии системы означает новую функциональность, а не набор новых дефектов, которые добавляются к уже существующим.
Уменьшение количества дефектов. Имею ли я право утверждать, что подобное возможно? Есть ли у меня научное доказательство?
Нет. На текущий момент не проводилось никаких исследований, подтверждающих преимущества TDD по сравнению с альтернативными подходами в смысле качества, эффективности или удовольствия. Однако эпизодические подтверждения преимуществ TDD многочисленны, а вторичные эффекты очевидны. При использовании TDD у программистов действительно снижается стресс, в командах действительно повышается доверие, а заказчики действительно начинают смотреть на каждую новую версию продукта с энтузиазмом. Лично мне не приходилось сталкиваться с обратными эффектами. Однако ваши наблюдения могут оказаться иными, вы должны попробовать для того, чтобы оценить TDD самостоятельно.
Еще одним преимуществом методики TDD, объясняющим ее положительные эффекты, является сокращение времени, которое проходит между принятием проектного решения и проверкой результата его реализации. В рамках TDD это достаточно короткий промежуток времени – несколько секунд или минут. Вы принимаете решение, реализуете его в коде, запускаете тесты и анализируете полученный результат. В начале у вас возникает мысль – возможно, API должен выглядеть так, или, возможно, метафора должна быть такой, – затем вы создаете самый первый пример – тест, который воплощает вашу мысль в реальность. Вместо того чтобы сначала проектировать, а затем в течение нескольких недель или месяцев ожидать, окажется ваше решение правильным или нет, вы получаете результат уже через несколько секунд или минут.
Причудливый ответ на вопрос, «Почему TDD работает?», основан на бредовом видении из области комплексных систем. Неподражаемый Флип пишет:
Следует использовать программистские практики, которые «притягивают» корректный код как предельную функцию, но не как абсолютную величину. Если вы пишете тесты для каждой присутствующей в системе функциональности, если вы добавляете в систему новые функции по одной, и только после того, как выполнятся все тесты, вы создадите то, что математики обозначают термином «точка притяжения (аттрактор)». Точка притяжения – это точка в пространстве состояний, к которой сходятся все потоки. Со временем код с большей вероятностью изменяется в лучшую сторону, а не в худшую; точка притяжения приближается к корректности, как предельная функция.
Это «корректность», которая устраивает всех программистов (за исключением, конечно же, тех, кто работает над медицинским или аэрокосмическим программным обеспечением). Я считаю, что важно быть знакомым с концепцией точки притяжения – ее не следует отвергать, ею не следует пренебрегать