Экстремальное программирование

Оценки необходимо делать исходя из опыта. Если вам надо ответить в течение недели, то в отличие от обычной игры в планирование вы не обладаете временем, достаточным для того, чтобы сформировать опыт. Вы должны оценивать исходя из предыдущего опыта разработки подобных систем. Если у вас нет предыдущего опыта разработки аналогичных систем, значит, вы не можете заниматься этим бизнесом.

После того как вы получите контракт, первая вещь, которую вам необ ходимо сделать, это вернуться обратно к начальным стадиям игры в планирование, благодаря чему вы немедленно проверите свою возможность выполнить условия контракта в срок.

Глава 16. Стратегия разработки

В отличие от стратегии менеджмента стратегия разработки радикально отличается от того, что принято считать общепризнанной мудростью, – мы будем тщательно формировать решение сегодняшней проблемы именно сегодня в надежде на то, что мы всегда сможем решить завтрашнюю проблему завтра.

В ХР метафора программирования используется для всех видов деятельности, благодаря чему все, чем вы занимаетесь, выглядит как программирование: программирование в ХР выглядит как программирование с некоторыми небольшими добавлениями, например, автоматическим тестированием. Однако разработка, как и все остальное в ХР, может показаться простой только на первый взгляд. Все составные части достаточно просты, чтобы их объяснить, однако использовать их совместно достаточно сложно. Как только вы начинаете практиковать ХР, у вас появляется страх. Как только появляется давление, возвращаются старые привычки.

Стратегия разработки начинается с планирования итерации. Постоянно выполняемая интеграция уменьшает количество конфликтов и является естественным завершением эпизода разработки. Коллективное владение стимулирует всю команду делать всю систему все лучше и лучше. Наконец, программирование парами связывает весь процесс в единое целое.

Постоянная интеграция

Никакой код не остается не интегрированным в систему в течение более чем двух часов. В завершение каждого эпизода разработки полученный код интегрируется в текущую версию системы, и при этом все тесты должны сработать на все 100%.

При идеальной постоянно продолжающейся интеграции каждый раз, когда вы изменяете метод, это изменение должно немедленно отражаться во всем остальном, пусть даже не принадлежащем вам коде. Если даже не принимать во внимание инфраструктуру и скорость обмена информацией, которые необходимы для обеспечения работы в таком стиле, это все равно может не сработать. Когда вы разрабатываете код, вы желаете чувствовать себя единственным программистом, работающим над проектом. Вы хотите нестись вперед на полной скорости, игнорируя взаимосвязи между изменениями, которые делаете вы, и изменениями, которые делают все остальные участники проекта. Когда изменения выходят из-под вашего контроля, иллюзия разрушается.

Интеграция через каждые несколько часов (не чаще чем через день) предоставляет множество преимуществ для обоих стилей – единственный программист и немедленная интеграция. Когда вы разрабатываете код, вы можете действовать так, как будто вы и ваш партнер – это единственная пара, работающая над проектом. Вы можете вносить в проект изменения тогда, когда вы этого хотите. После этого роли меняются. Когда вы приступаете к интеграции, вы узнаете (специальные средства сообщают вам об этом) о том, в каких именно определениях классов и методов возникли конфликты. Запустив тесты, вы узнаете о семантических конфликтах.

Если интеграция отнимает у вас пару часов, работать в таком стиле становится невозможно. Чтобы обеспечить эффективную работу, необходимо использовать инструменты, которые обеспечивают быстрый цикл интеграция/сборка/тестирование. Вы также должны обладать достаточно быстрым набором тестов, для срабатывания которого требуется всего несколько минут. Усилия, которые вам потребуются для того, чтобы устранить конфликты, не должны быть слишком большими.

На самом деле это не такая уж серьезная проблема. В результате постоянной переработки кода система разбивается на множество небольших объектов и множество небольших методов. Благодаря этому снижается вероятность того, что две пары программистов в одно и то же время занимаются модификацией одного и того же метода или класса. Если же это на самом деле происходит, чтобы уладить возникшие при этом конфликты, требуется приложить совсем небольшие усилия, потому что каждая из версий одного и того же кода была создана в течение всего нескольких часов разработки.