Еще одной важной причиной, по которой следует смириться с затратами, вызванными постоянной интеграцией, является то, что при этом существенно снижается общий риск всего проекта. Если у двух разных людей в голове рождаются две разные идеи о том, как должен выглядеть или функционировать некоторый кусок кода, вы узнаете об этом буквально через несколько часов. То есть вам не придется тратить несколько дней на поиск ошибки, которая возникла уже достаточно значительное время назад – в ходе двух-трех минувших недель работы над программой. Кроме того, вся эта практика постоянной интеграции оказывается чрезвычайно полезной при создании финальной рабочей версии проекта. Оказывается, что сборка готовой к поставке заказчику версии – это не такая уж серьезная проблема. Любой программист в команде сможет собрать финальную версию почти что с завязанными глазами, так как все они занимались этим по несколько раз на дню в течение нескольких месяцев.
Постоянно продолжающаяся интеграция обеспечивает значительное преимущество также с точки зрения человеческого фактора. В процессе работы над задачей в вашей голове рождается множество связанных с этим мыслей. Когда вы завершаете решение задачи и приступаете к интеграции, это означает, что ваш список дел, которые вы должны сделать, очистился. Вы очищаете свою голову от вещей, которые предстоит сделать, и приступаете к анализу того, что получилось в результате. Таким образом, интеграция обеспечивает естественный ритм разработки. Размышление/тестирование/кодирование/выпуск готового кода. Это почти так же естественно, как дыхание. Вы формируете идею, вы формулируете ее, затем вы добавляете ее в систему. Теперь ваша память свободна и готова к следующей идее.
Время от времени постоянно выполняемая интеграция принуждает вас разделить реализацию задачи на два эпизода. Необходимо принять дополнительные связанные с этим затраты и помнить, что уже сделано, а что только предстоит сделать. В промежутке времени между двумя эпизодами возможно у вас появится предположение о том, почему первый эпизод затянулся столь надолго. Вы можете начать следующий эпизод с переработки кода, и тогда весь второй эпизод пройдет более гладко.
Коллективное владение
Коллективное владение – это на первый взгляд бредовая идея, предполагающая, что кто угодно имеет право изменять любой кусок кода в каком угодно месте системы в любое удобное для этого время. Если вы не практикуете автоматическое тестирование, применять коллективное владение на практике – это верный способ самоубийства. Однако с использованием тестирования и благодаря тому, что качество ваших тестов спустя месяцы практики в этом направлении будет достаточно высоким, вы можете смело использовать коллективное владение. Для того чтобы без опаски применять коллективное владение, необходимо также осуществлять интеграцию каждые несколько часов работы над проектом. Именно всем этим, конечно же, вы и будете заниматься в рамках ХР.