Главная » Архитектура ПО » Не увлекайтесь архитектурными метафорами

0

Дэвид Инг

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

Обычно все начинается хорошо: собеседники находят общий язык, и кажется, что все идет в нужном направлении. Метафора развивается и растет до тех пор, пока не начинает жить собственной жизнью. Люди относятся к ней благосклонно – прогресс налицо!

А затем обычно наступает момент, когда архитектурная метафора вдруг становится опасной и восстает против своих создателей. Вот как это может происходить:

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

Пример: «Мы строим транспортную систему по принципу перемещения корабля между несколькими причалами».

Вы представляете себе контейнеровоз, бороздящий просторы Тихого океана, – я же имел в виду гребную лодку в бассейне, притом с одним веслом.

•      Команда разработчиков начинает считать метафору более весомой по сравнению с реальной бизнес-задачей. А вы из любви к своей метафоре начинаете оправдывать странные решения.

Пример: «Мы сказали, что система будет похожа на картотечный шкаф, поэтому нам придется выводить данные в алфавитном порядке. Я знаю, что этот шкаф имеет шесть измерений, бесконечную длину и встроенные часы, но мы уже сделали иконку – а картотека должна вести себя как картотека…».

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

Пример: «А почему объект Billing Factory1 создает Port Channel для системы Rowing boat?.. И он в самом деле должен возвращать для Hub Bus представление Pomegranate?.. Ну да, я действительно работаю здесь недавно, а что?»

Итак, не влюбляйтесь в метафору, представляющую вашу систему, используйте ее в целях исследований и разъяснения, но не попадайте под ее влияние.

Дэвид Инг (David Ing) – архитектор программного обеспечения, живущий и работающий в Ванкувере. Родился в Великобритании, но переехал подаль* ше от дождей (хотя сейчас считает, что был обманут лживой литературой для туристов ).

Подчиняясь требованиям моды, сейчас Дэвид работает в компании Taglo- city, специализирующейся на Web 2.0; здесь он пытается привести системы электронной почты «к цивилизованному виду», а заодно понять, что же такое Web 2.0.

Billing Factory – фабрика счетов («Фабрика» – один из шаблонов проектирования); port channel – агрегирование каналов (технология, позволяющая объединить несколько физических каналов в один логический, в данном случае – отвечающий за это программный объект); rowing boat – гребная лодка; hub bus – концентратор шины; pomegranate – гранат. (Поскольку программные объекты обычно имеют английские названия, то в российской компании подобный разговор происходил бы именно так – на смеси русского и английского. Поэтому мы сочли правильным привести переводы и дать пояснения в сноске, а не напрямую в тексте.) – Примеч. ред.

Источник: Форд Н., Найгард М., де Ора Б., 97 этюдов для архитекторов программных систем. – Пер. с англ. – СПб.: Сим- вол-Плюс, 2010. – 224 с., ил.

По теме:

  • Комментарии