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

Менеджер стал со мной спорить: Этот парень реальный биржевой брокер, выяснилось, что он умеет также и программировать. Другие брокеры любят и уважают его. Они уверены в нем и желают видеть его в качестве своего доверителя. Он обладает четким представлением о том, в каком направлении должна развиваться система. Другие программисты хорошо различают, когда он разговаривает от лица заказчика и когда он разговаривает от лица технического специалиста.

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

Программист

Программист является сердцем ХР. На самом деле если бы программисты могли всегда принимать решения, в которых тщательно балансировались краткосрочные и долгосрочные приоритеты, в рамках проекта не нужны были бы никакие другие технические работники, кроме программистов.

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

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

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

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