• Принятие ответственности.
Вот что говорит Атул Гаванде (Atul Gawande) в своей замечательной книге «Better: A Surgeon’s Notes on Performance» (Быть лучше: записки хирурга о профессиональном мастерстве) (Metropolitan Books) об усердии в медицинском сообществе:
«Добиться истинного успеха в медицине нелегко. Это требует силы воли, внимания к мелочам и творческого подхода. Но из своего пребывания в Индии я вынес урок: это может сделать кто угодно и где угодно. Найдется очень мало мест с еще более трудными условиями. Но и там встречались поразительные успехи… Я понял, что стать лучше всегда возможно. Для этого не обязательна гениальность. Необходимо усердие. Необходимы моральные принципы. Необходима изобретательность. И самое главное — желание попытаться.»
Брайан Харт (Brian Hart) — ведущий консультант no CGI, специалист в области информационных технологий и бизнес-процессов. Брайан участвовал в проектировании приложений J2EE, главным образом в государственном секторе и на уровне местных властей. В сфере разработки программного обеспечения работает с 1997 года.
Отвечайте за свои решения
И Чжоу
Архитекторы программного обеспечения должны отвечать за свои решения, так как они влияют на ход проекта гораздо сильнее, чем большинство других сотрудников организации. Анализ программных проектов показывает, что более двух третей из них заканчиваются либо полным крахом, либо выпуском продукта с нарушениями (перенос срока выпуска, перерасход бюджета, недовольство заказчика). Глубинные причины неудач чаще всего связаны с неверными решениями, принятыми архитектором, или с неверным осуществлением правильных архитектурных решений.
Как стать ответственным архитектором, принимающим эффективные архитектурные решения?
Во-первых, вы должны хорошо знать процесс принятия решений независимо от того, относится ли он к гибким или традиционным методологиям. Нельзя сказать, что архитектурное решение принято, пока не выполнены следующие два условия:
• Решение изложено в письменном виде, поскольку архитектурные решения редко бывают тривиальными. Они должны быть четко обоснованными и отслеживаемыми вплоть до источника.
• Информация о решении передана исполнителям, а также тем людям, которых оно затронет (прямо или косвенно). Передача информации формирует единое для всех понимание сути решения.
Во-вторых, регулярно возвращайтесь к анализу своих архитектурных решений. Сопоставляйте результаты своих решений с исходными ожиданиями. Определяйте, какие архитектурные решения доказали свою правильность, а какие нет.
В-третьих, обеспечьте выполнение своих архитектурных решений. Во многих программных проектах архитектор участвует только в фазе проектирования, а затем переходит на другой проект (или же контракт на оказание консультационных услуг подходит к концу). Как в такой ситуации он может проследить за правильностью реализации своих тщательно проработанных архитектурных решений? Без авторского контроля за исполнением решения в лучшем случае останутся благими намерениями.
Наконец, доверьте принятие некоторых решений другим специалистам в предметной области задачи. Многие архитекторы ошибочно полагают, что они должны принимать все архитектурные решения без исключения, то есть играют роль экспертов «в чем угодно». В действительности универсальных технических гениев не бывает. У каждого архитектора есть области, в которых он хорошо разбирается, области, в которых он что-то знает, и области, в которых он попросту некомпетентен. Грамотный архитектор делегирует другим принятие решений в тех областях, в которых плохо ориентируется сам.
И Чжоу (Yi Zhou) в настоящее время работает главным архитектором программного обеспечения в широко известной биотехнологической компании, где проектирует программные платформы для медицинских устройств и персонализации управления ходом заболевания. Он обладает почти 20-летним опытом, охватывающим все стадии цикла разработки ПО, и специализируется на согласовании бизнеса и технологий, стратегическом планировании, совершенствовании процессов, проектировании архитектур и инфраструктур, создании проектных команд и управлении ими, а также на консультировании.
Не мудрствуйте
Эбен Хьюит
Интеллект, изобретательность, вдумчивость, широта и глубина познаний, любовь к точности — качества, похвальные для любого человека и особенно ценные для архитекторов.
Однако изощренность ума имеет побочный смысловой оттенок. Да, она подразумевает умение моментально найти решение, которое выведет вас из сложной ситуации, но в конечном счете это решение опирается на фокус, ловкость рук, трюк сродни игре в «наперсток». Вспомните умных спорщиков, с которыми вы вместе учились, — они всегда умели поиграть на семантике или использовать логические слабости в позиции оппонента, чтобы победить в споре.
Умные программы обходятся дорого, сложны в сопровождении и ненадежны. Не мудрствуйте. Постарайтесь быть как можно примитивнее, но создайте при этом подходящий дизайн. Самый подходящий дизайн никогда не бывает умным. Если вам кажется, что без ухищрений не обойтись, значит, задача неправильно структурирована, — проанализируйте ее заново. Пересматривайте постановку задачи до тех пор, пока вы не сможете снова действовать примитивно. Работайте на уровне грубых набросков; придерживайтесь общих решений. Забудьте о новомодных веяниях. Умный архитектор должен действовать как можно примитивнее.
Именно изощренность ума позволяет нам «обмануть» нежизнеспособную систему и заставить ее работать. Не становитесь адвокатом, который своим красноречием «спасает» программу на техническом суде. Вы не Руб Голдберг и не Макгайвер,[39] готовый в любой момент построить умопомрачительную конструкцию из скрепок, жевательной резинки и динамитной шашки. Выкиньте все лишнее из головы; подойдите к решению задачи без своих обширных познаний в области замыканий, обобщений и управления поколениями объектов в «куче». Иногда, конечно, все перечисленное действительно нужно для решения задачи, но намного реже, чем кажется на первый взгляд.
Чем примитивнее решение, тем больше разработчиков справятся с его реализацией и сопровождением. В примитивных решениях каждый компонент выполняет ровно одну функцию. Они быстрее создаются и легче модифицируются в будущем. Они наследуют оптимизацию от структурных блоков, которые используются при их построении. Такие решения уже на бумаге выглядят жизнеспособными, и при первом взгляде на них ощущается их элегантность и простота. В то же время умный, изощренный дизайн запутывает общую картину в хитросплетении деталей и разваливается от малейшего прикосновения.
Эбен Хьюит (Eben Hewitt) возглавляет группу архитекторов в национальной компании розничной торговли с миллиардным оборотом, где в настоящее время занимается проектированием и реализацией сервис-ориентированной архитектуры (SOA). Он является автором книги «Java SOA Cookbook», которая будет скоро опубликована издательством O’Reilly.
Выбирайте оружие тщательно и не спешите его менять
Чед Лавинь
Любой архитектор, будучи закаленным ветераном проектирования и реализации, обладает целым арсеналом «оружия», которое он раз за разом успешно применяет в своей работе. По тем или иным причинам эти технологии завоевали наше расположение и сумели подняться на первые позиции в нашем личном списке предпочтений. Скорее всего, они заслужили свое место в арсенале, победив в ходе ожесточенной конкуренции. Однако, несмотря на это, их положению постоянно угрожают многочисленные новые технологии. У нас часто возникает соблазн отложить свое испытанное оружие, чтобы опробовать новые альтернативы… но не стоит торопиться. Отказываться от проверенных инструментов в пользу других технологий, которые еще не прошли аналогичной проверки, — дело весьма рискованное.
