Малыш, хочешь быть архитектором, когда вырастешь?
За последнее десять лет стало очень популярно словосочетание "архитектор программного обеспечения". Лично мне такой термин использовать очень трудно. Дело в том, что моя жена - инженер-строитель. А отношения между архитекторами и инженерами-строителями несколько.... натянуты. Инженеры полагают, что архитекторам ничего не стоит нарисовать целый ворох симпатичных рисуночков, а потом инженеры должны в поте лица вычислять, сможет такая симпатичная конструкция держаться вертикально, или сразу развалится. Именно поэтому я всегда старался избегать термина "архитектор". Сами судите, если моя собственная жена не станет относиться ко мне с профессиональным уважением, то чего мне ждать от остальных?
В области программирования термин "архитектор" имеет множество значений. (Впрочем, в области программирования любой термин имеет множество значений.) Однако, как правило, здесь присутствует некий подтекст: "Я уже не просто какой-то там программист, я - архитектор", что можно понять как "Теперь я архитектор, и мне не пристало заниматься программированием". Вопрос только в том, действительно ли нужно отказываться от тривиального программирования, если собираешься стать техническим лидером.
Такой вопрос обычно вызывает бурю эмоций. Сколько раз я видел, как люди не на шутку сердились при мысли, что как архитекторы они уже не играют столь важной роли. "В ХР нет места опытным архитекторам!" - такой вопль я слышу довольно часто.
Все это напоминает положение дел с проектированием в целом. Я не думаю, что при использовании методологии ХР исчезает необходимость в умении хорошо проектировать. Более того, именно благодаря основоположникам ХР - Кенту Беку, Бобу Мартину, и конечно же, Уорду Каннингэму - я, в свое время, узнал, что такое настоящее проектирование. Однако сейчас многим может показаться, что эти люди перестали играть роль технических лидеров (в общепринятом понимании).
Для примера можно взять одного из технических лидеров компании "ThoughtWorks", по имени Дэйв Райс (Dave Rice).
Дэйв уже давно работает в компании и заслужил неофициальную мантию технического лидера в проекте, над которым работает около пятидесяти человек. Что же означает его лидерство? В первую очередь, то, что он проводит большую часть времени с программистами. Он помогает тем, кому это необходимо, и старается быть рядом на случай, если его помощь понадобится. Интересно отметить, где располагается его рабочее место. Как заслуженный сотрудник компании, он мог бы выбрать любое помещение по своему желанию. Какое-то время назад он сидел в офисе с Кара (Cara), который отвечал за выпуск системы. Тем не менее, вот уже несколько месяцев, как Дэйв перебрался в комнату к программистам (в том самом стиле "war room", который превозносит ХР). Для него очень важно находиться вместе с разработчиками, потому что в этом случае он знает, что происходит, и всегда может протянуть руку помощи тем, кто находится в затруднении.
Те, кто уже знаком с методологией ХР, поймут, что я описал имеющееся там понятие "тренера" ("coach"). Это еще один пример игры словами, которую так любят в ХР. Технический лидер команды называется "тренером". Подтекст понятен каждому: в ХР лидер учит программистов и помогает им принимать решения. Чтобы быть тренером, нужны не только отличные технические знания, но и хорошие качества человеческой натуры. Как заметил Джек Боллс (Jack Bolles) на конференции ХР 2000, для знатоков-одиночек скоро вообще не останется места. Ключ к успеху - обучение и взаимопомощь.
Позже, на обеде, который состоялся после конференции, Дэйв и я разговаривали с человеком, который критиковал ХР. Мы начали обсуждать все более подробно, и к удивлению, выяснили, насколько похожи наши подходы. Все мы предпочитали адаптивные, итеративные разработки. Все соглашались с важностью тестирования. Мы с Дэйвом никак не могли понять, откуда же тогда такое неприятие ХР? И тут наш оппонент сказал замечательную фразу: "последнее, что я допущу у себя на работе, это чтобы мои программисты делали рефакторинг и совали нос в проектирование".После этого все стало ясно. Итог нашим концептуальным разногласиям подвел Дэйв, когда сказал мне напоследок: "Интересно, зачем брать на работу программистов, если ты им не доверяешь?" В ХР самое ценное, что может сделать опытный разработчик - это передать свои знания младшим коллегам. Вместо архитектора, который один уполномочен принимать все важные решения, у вас есть тренер, который учит, как нужно принимать такие решения. Как говорит Уорд Каннингэм, таким образом опытный разработчик распространяет свои знания, и приносит проекту гораздо больше пользы, чем любой герой-одиночка.
