Я
пытался
игнорировать
случайные
элементы
списка
и
программировать по прихоти, од нако это не позволяет разорвать
замкнутый круг.
Я выработал привычку записывать на листок бумаги все зад ачи,
которые планирую решить в течение нескольких след ующих часов. Этот
листок по стоянно лежит ряд ом с моим компьютером. Похожий список
зад ач, которые я планирую решить в течение ближайшей нед ели или
ближайшего месяца, приколот к стене над моим компьютером.
Если я
записал все эти зад ачи на бумагу, я уверен в том, что я ничего не забуд у.
Если перед о мной возникает новая зад ача, я быстро и о сознанно решаю,
к какому списку («сейчас» или «позд нее») она принад лежит и нужно ли
вообще ею заниматься.
В контексте разработки через тестирование, список зад ач – это
список тестов, которые мы планируем реализовать. Прежд е всего
включите в список примеры всех операций, которые требуется
реализовать. Далее, д ля кажд ой из операций, которые еще не
существуют, внесите в список нуль-версию этой операции. Наконец,
перечислите в списке все изменения, которые потребуется выполнить,
чтобы в конце сеанса программирования получить чистый код .
Но зачем записывать тесты на бумагу, когд а можно записать их од ин
за д ругим в вид е готового тестирующего код а?
Существует пара
причин, по которым я не рекоменд ую заниматься массовым созд анием
тестов. Во-первых, кажд ый из тестов созд ает некоторую инерцию,
мешающую выполнению рефакторинга. Чем больше тестов, тем больше
эта инерция. Согласитесь, что выполнить рефакторинг код а, д ля
тестирования которого написаны д ва теста, сложнее, чем выполнить
рефакторинг код а, д ля тестирования которого написан всего од ин тест.
Конечно, существуют инструменты автоматизированного рефакторинга,
которые упрощают эту зад ачу (например, специальный пункт в меню
о существляет мод ификацию
имени переменной в строке, гд е она
объявляется, и во всех местах, в которых эта переменная используется).
Од нако пред ставьте, что вы написали д есять тестов д ля некоторого
метод а и
после
этого обнаружили, что поряд ок аргументов метод а
след ует изменить на обратный. В под обной ситуации прид ется
приложить существенные усилия, чтобы заставить себя сд елать
рефакторинг.
Во-вторых, чем больше не работающих тестов, тем
д ольше путь к зеленой поло се. Если перед вами д есять «сломанных»
тестов, зеленую поло су вы увид ите еще не скоро. Если вы хотите
быстро получить перед собой зеленую поло су, вы д олжны выкинуть все
д есять тестов. Если же вы хотите д обиться успешного выполнения всех
этих тестов, вы буд ете вынужд ены д олгое время смотреть на красную
поло су. Если вы настолько приучены к опрятно сти и аккуратно сти
код ирования, что не можете позволить себе д аже д ойти д о туалета, пока
висит красная поло са, значит, вам пред стоит серьезное испытание.
Консервативные скалолазы прид ерживаются од ного важного
правила. У человека есть д ве руки и д ве ноги, всего четыре конечно сти,
которыми он может цепляться за скалу. В любой момент по крайней мере
три конечно сти д олжны быть над ежно сцеплены со скалой.
Динамические перемещения, когд а скалолаз перемещает с места на
место
од новременно
д ве
конечно сти,
считаются
чрезвычайно
опасными. Метод ика TDD в чистом вид е
под разумевает использование
похожего принципа: в любой момент времени вы д олжны быть не
д альше од ного изменения от зеленой поло сы.
По мере того как вы заставляете тесты срабатывать, перед вами
буд ет возникать необход имо сть реализации новых тестов. Зано сите эти
новые тесты в список зад ач. То же самое отно сится и к рефакторингу.
«Это выгляд ит ужасно <взд ох>. Добавим это в список. Мы вернемся
к этому перед тем, как завершить работу над зад ачей.»
Необход имо позаботиться о пунктах, о ставшихся в списке на
момент завершения сеанса программирования. Если на самом д еле вы
наход итесь
в
серед ине
процесса
реализации
некоторой
функционально сти, во спользуйтесь этим же списком позд нее. Если вы
обнаружили необход имо сть выполнения более крупномасштабного
рефакторинга,
выполнить
который
в
настоящий
момент
не
пред ставляется
возможным, внесите его в список «позд нее». Я не могу
припомнить ситуации, когд а мне приход ило сь перено сить реализацию
теста в список «позд нее». Если я могу прид умать тест, который может
не сработать, реализация этого теста важнее, чем выпуск код а, над
которым я работаю.
Do'stlaringiz bilan baham: 
