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

обоснованные деловые решения. Здесь важнейшую роль играет прозрачность. Архитектор вместе с руководством проекта должен создать и усовершенствовать средства получения регулярной, оперативной обратной связи. Этой цели можно достичь, применяя различные приемы бережливой разработки ПО (lean software development): большие, заметные диаграммы, непрерывная интеграция, частые выпуски рабочих версий продукта и их передача бизнес-руководству уже на самых ранних стадиях проекта.

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

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

Дэйв Мурхед (Dave Muirhead) — ветеран в области искусства программирования и бизнес-технологий, владелец и ведущий консультант Blue River Systems Group, LLC (BRSG) — расположенной в Денвере компании, оказывающей консультационные услуги в сфере бережливой разработки программного обеспечения и технических стратегий.

Простота лучше универсальности

Кевлин Хенни

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

Приоритет простоты перед универсальностью помогает сделать выбор между двумя архитектурными альтернативами, равнозначными в остальных отношениях. Когда возможны два решения, отдавайте предпочтение более простому и ориентированному на конкретную потребность, а не более изощренному и претендующему на универсальность. Конечно, вполне может случиться (и не так уж редко случается), что более простое решение на практике окажется и более универсальным. Но, даже если этого не произойдет, легче изменить простое решение, когда вы хорошо представляете, что же вам требуется, нежели нужным образом адаптировать «универсальное» решение, которое, как назло, оказалось недостаточно универсальным.

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

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

Многие архитекторы высоко ценят универсальность, но такое отношение не должно быть безусловным. Как правило, люди не готовы платить за универсальность (или не нуждаются в ней): перед ними обычно стоит совершенно конкретная задача, и они ценят конкретное решение этой задачи. Универсальность и гибкость могут проявиться при создании конкретных решений, но если при этом мы слишком быстро снимемся с якоря и забудем о конкретике, то начнем дрейфовать в море безграничных возможностей — море, полном хитроумных настроек, громоздких (не просто обширных) списков параметров, бескрайних интерфейсов и неправомерных абстракций. В стремлении к абстрактной гибкости часто (случайно или намеренно) утрачиваются ценные свойства альтернативных, более простых решений.

Кевлин Хенни (Kevlin Неппеу) — независимый консультант и преподаватель. Он специализируется на шаблонах и архитектуре, методах и языках программирования, процессах и практике разработки. Является соавтором книг «А Pattern Language for Distributed Computing» (Язык шаблонов для распределенных компьютерных систем) и «On Patterns and Pattern Languages» (О шаблонах и языках шаблонов) — обе книги опубликованы издательством Wiley.

Архитектор должен быть практиком

Джон Дэвис

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

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

Лучший способ обучаться — наблюдать за другими; именно так мы учимся в детстве. Хороший