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