По ту сторону кодинга

Алексей Башкеев

Спецвыпуск: Хакер, номер #053, стр. 053-068-2

Кодинг в ХП

Философия ХП затрагивает и этот аспект выполнения проекта. Даже если техническое задание правильно поставлено, разделено на части, распределенные между программистами, которые знают свое дело, проблемы все равно могут иметь место. Уволился или заболел сотрудник, который написал половину кода. Или одному программисту надо воспользоваться модулем, который написан другим. Или заказчик, увидев программу на промежуточной стадии ее разработки, вдруг воскликнул "О боже, это ведь не то, что я хотел!". На этот случай, как ты уже догадался, в ХП тоже имеются свои правила.

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

Работа в команде

ХП – это прежде всего командный стиль программирования, созданный для команд и в котором командному духу уделяется особое внимание. В этом плане в ХП есть множество методов, которые нельзя не упомянуть.

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

Утренние собрания стоя. Каждый день команды "экстремальных программистов" должен начинаться с такого собрания, на котором обсуждаются текущие планы. Стоя – чтобы не увлекаться и засиживаться, а говорить по существу. Такие собрания позволяют любому сотруднику команды получить представление о том, что делает другой, и высказывать свои идеи и предложения для чужого сектора.