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

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

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

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

Кевлин Хенни

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

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

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

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

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