97 этюдов для архитекторов программных систем - Нил Форд

• Решение изложено в письменном виде, поскольку архитектурные решения редко бывают тривиальными. Они должны быть четко обоснованными и отслеживаемыми вплоть до источника.

• Информация о решении передана исполнителям, а также тем людям, которых оно затронет (прямо или косвенно). Передача информации формирует единое для всех понимание сути решения.

Во-вторых, регулярно возвращайтесь к анализу своих архитектурных решений. Сопоставляйте результаты своих решений с исходными ожиданиями. Определяйте, какие архитектурные решения доказали свою правильность, а какие нет.

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

Наконец, доверьте принятие некоторых решений другим специалистам в предметной области задачи. Многие архитекторы ошибочно полагают, что они должны принимать все архитектурные решения без исключения, то есть играют роль экспертов «в чем угодно». В действительности универсальных технических гениев не бывает. У каждого архитектора есть области, в которых он хорошо разбирается, области, в которых он что-то знает, и области, в которых он попросту некомпетентен. Грамотный архитектор делегирует другим принятие решений в тех областях, в которых плохо ориентируется сам.

И Чжоу (Yi Zhou) в настоящее время работает главным архитектором программного обеспечения в широко известной биотехнологической компании, где проектирует программные платформы для медицинских устройств и персонализации управления ходом заболевания. Он обладает почти 20-летним опытом, охватывающим все стадии цикла разработки ПО, и специализируется на согласовании бизнеса и технологий, стратегическом планировании, совершенствовании процессов, проектировании архитектур и инфраструктур, создании проектных команд и управлении ими, а также на консультировании.

Не мудрствуйте

Эбен Хьюит

Интеллект, изобретательность, вдумчивость, широта и глубина познаний, любовь к точности — качества, похвальные для любого человека и особенно ценные для архитекторов.

Однако изощренность ума имеет побочный смысловой оттенок. Да, она подразумевает умение моментально найти решение, которое выведет вас из сложной ситуации, но в конечном счете это решение опирается на фокус, ловкость рук, трюк сродни игре в «наперсток». Вспомните умных спорщиков, с которыми вы вместе учились, — они всегда умели поиграть на семантике или использовать логические слабости в позиции оппонента, чтобы победить в споре.

Умные программы обходятся дорого, сложны в сопровождении и ненадежны. Не мудрствуйте. Постарайтесь быть как можно примитивнее, но создайте при этом подходящий дизайн. Самый подходящий дизайн никогда не бывает умным. Если вам кажется, что без ухищрений не обойтись, значит, задача неправильно структурирована, — проанализируйте ее заново. Пересматривайте постановку задачи до тех пор, пока вы не сможете снова действовать примитивно. Работайте на уровне грубых набросков; придерживайтесь общих решений. Забудьте о новомодных веяниях. Умный архитектор должен действовать как можно примитивнее.

Именно изощренность ума позволяет нам «обмануть» нежизнеспособную систему и заставить ее работать. Не становитесь адвокатом, который своим красноречием «спасает» программу на техническом суде. Вы не Руб Голдберг и не Макгайвер,[39] готовый в любой момент построить умопомрачительную конструкцию из скрепок, жевательной резинки и динамитной шашки. Выкиньте все лишнее из головы; подойдите к решению задачи без своих обширных познаний в области замыканий, обобщений и управления поколениями объектов в «куче». Иногда, конечно, все перечисленное действительно нужно для решения задачи, но намного реже, чем кажется на первый взгляд.

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

Эбен Хьюит (Eben Hewitt) возглавляет группу архитекторов в национальной компании розничной торговли с миллиардным оборотом, где в настоящее время занимается проектированием и реализацией сервис-ориентированной архитектуры (SOA). Он является автором книги «Java SOA Cookbook», которая будет скоро опубликована издательством O’Reilly.

Выбирайте оружие тщательно и не спешите его менять

Чед Лавинь

Любой архитектор, будучи закаленным ветераном проектирования и реализации, обладает целым арсеналом «оружия», которое он раз за разом успешно применяет в своей работе. По тем или иным причинам эти технологии завоевали наше расположение и сумели подняться на первые позиции в нашем личном списке предпочтений. Скорее всего, они заслужили свое место в арсенале, победив в ходе ожесточенной конкуренции. Однако, несмотря на это, их положению постоянно угрожают многочисленные новые технологии. У нас часто возникает соблазн отложить свое испытанное оружие, чтобы опробовать новые альтернативы… но не стоит торопиться. Отказываться от проверенных инструментов в пользу других технологий, которые еще не прошли аналогичной проверки, — дело весьма рискованное.

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

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

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