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