Я использовал подобный трюк при работе над моими одиночными проектами и мне очень понравился эффект. В конце рабочего сеанса следует написать тест и запустить его, чтобы убедиться, что он не работает. Вернувшись к коду, вы сразу увидите место, откуда можно продолжить. Вы получаете хорошо заметную закладку, которая помогает вам вспомнить, о чем вы думали. Оставленный неработающим тест должен быть прост в реализации, благодаря чему вы сможете быстро выйти на прежний маршрут и продолжить движение к победе.
Сначала я думал, что оставленный недоделанным тест будет действовать мне на нервы. Однако нет. Ведь вся программа в целом еще далека от завершения, один сломанный тест не сделает ее менее завершенной, и я отлично знаю об этом. Возможность быстро восстановить общий ход разработки спустя несколько недель простоя стоит того, чтобы немножко поступиться принципами и оставить работу, имея перед глазами красную полосу.
Чистый выпускаемый код (Clean Check-in)
Как следует завершить сеанс программирования, если вы программируете в составе команды? Все ваши тесты должны работать.
Я противоречу сам себе? Да.
Бубба Уитман (Bubba Whitman), брат Уолта – портового грузчика
Когда вы работаете над кодом не один, а вместе с вашими коллегами, ситуация полностью меняется. Когда вы возвращаетесь к работе над кодом, над которым помимо вас работают еще несколько человек, вы не можете сказать точно, что именно произошло с кодом с того момента, как вы видели его последний раз. По этой причине, прежде чем выпускать разрабатываемый вами код, убедитесь, что все тесты выполняются успешно. (Это напоминает правило изоляции тестов, в соответствии с которым каждый тест гарантированно оставляет систему в хорошем известном состоянии. Это правило можно применить и в отношении программистов, которые поочередно интегрируют свой код в систему, каждый раз проверяя, остается система в хорошем состоянии или нет.)
Набор тестов, которые вы запускаете в ходе интеграции, может быть существенно объемнее набора тестов, который вы запускаете каждую минуту в процессе разработки функциональности. (До того времени, пока это не станет слишком утомительным, я рекомендую вам постоянно запускать полный набор тестов.) Что делать, если при попытке интеграции вы обнаружили, что один тест из полного набора завершается неудачей?
Самое простое правило: отбросьте проделанную работу и начните все заново. Сломанный сигнализирует, что вы не обладаете достаточным запасом знаний, чтобы запрограммировать то, над чем вы работаете. Если команда будет действовать в соответствии с этим правилом, у ее членов появится тенденция выполнять интеграцию более часто, так как тот, кто успеет приступить к интеграции раньше других, не рискует потерять проделанную работу. По всей видимости, частая интеграция и проверка – это неплохая практика.
