Форма входа
Книга онлайн » Компьютеры и Интернет » Программирование » 97 этюдов для архитекторов программных систем - Нил Форд
Читем онлайн 97 этюдов для архитекторов программных систем - Нил Форд
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
Дэвид Инг
Архитекторы обожают иметь дело с метафорами. Метафоры позволяют придать осязаемость абстрактным, сложным и ускользающим от понимания темам. При общении с другими членами команды или в процессе обсуждения архитектуры с конечным пользователем возникает неодолимый соблазн подобрать выразительную, хорошо знакомую по реальному миру метафору, которая описала бы то, что вы пытаетесь построить.
Обычно все начинается хорошо: собеседники находят общий язык, и кажется, что все идет в нужном направлении. Метафора развивается и растет до тех пор, пока не начинает жить собственной жизнью. Люди относятся к ней благосклонно — прогресс налицо!
А затем обычно наступает момент, когда архитектурная метафора вдруг становится опасной и восстает против своих создателей. Вот как это может происходить:
• Ваша метафора начинает нравиться заказчику больше, чем сама разрабатываемая система, то есть все заинтересованные стороны начинают верить в красивую иллюзию, созданную метафорой, не желая разбираться, что за ней на самом деле скрывается.
Пример: «Мы строим транспортную систему по принципу перемещения корабля между несколькими причалами».
Вы представляете себе контейнеровоз, бороздящий просторы Тихого океана, — я же имел в виду гребную лодку в бассейне, притом с одним веслом.
• Команда разработчиков начинает считать метафору более весомой по сравнению с реальной бизнес-задачей. А вы из любви к своей метафоре начинаете оправдывать странные решения.
Пример: «Мы сказали, что система будет похожа на картотечный шкаф, поэтому нам придется выводить данные в алфавитном порядке. Я знаю, что этот шкаф имеет шесть измерений, бесконечную длину и встроенные часы, но мы уже сделали иконку — а картотека должна вести себя как картотека…».
• В системе попадаются названия из старых, давно забытых метафор — археологические реликты концепций, давно отправленных в утиль.
Пример: «А почему объект Billing Factory[34] создает Port Channel для системы Rowing boat?.. И он в самом деле должен возвращать для Hub Bus представление Pomegranate?.. Ну да, я действительно работаю здесь недавно, а что?»
Итак, не влюбляйтесь в метафору, представляющую вашу систему, используйте ее в целях исследований и разъяснения, но не попадайте под ее влияние.
Дэвид Инг (David Ing) — архитектор программного обеспечения, живущий и работающий в Ванкувере. Родился в Великобритании, но переехал подальше от дождей (хотя сейчас считает, что был обманут лживой литературой для туристов). Подчиняясь требованиям моды, сейчас Дэвид работает в компании Taglocity, специализирующейся на Web 2.0; здесь он пытается привести системы электронной почты «к цивилизованному виду», а заодно понять, что же такое Web 2.0.
Уделяйте пристальное внимание поддержке и сопровождению
Мнчедизи Каспер
Поддержка и сопровождение приложений никогда и ни при каких обстоятельствах не должны отходить на второй план. Поскольку более 80 % жизненного цикла приложения занимает стадия сопровождения, вы должны уже на стадии проектирования обратить пристальное внимание на проблемы поддержки и сопровождения. Стоит вам забыть об этом, и вскоре вы с ужасом будете взирать на то, как ваше приложение превращается из мечты архитектора в нечто отвратительное, гибнет в конвульсиях и навечно остается в памяти людей как ваша неудача.
В ходе проектирования приложения перед внутренним взором архитекторов находятся главным образом разработчики, вооруженные интегрированными средами и отладчиками. Если что-то идет не так, искусные программисты переключаются в режим отладки и находят ошибку. Такая картина вполне естественна, поскольку большинство архитекторов основную часть своей жизни проводят в роли разработчиков, а не администраторов системы. К сожалению, разработчик и специалист службы поддержки обладают разными навыками — аналогично тому, как среда разработки/тестирования и рабочая среда (production environment) служат разным целям.
Вот примеры проблем, с которыми сталкивается администратор системы:
• Администратор не может заново отправить запрос, чтобы воспроизвести проблему. В рабочей среде вы не можете выполнить финансовую транзакцию в «боевой» базе данных, чтобы просто посмотреть, где произошла ошибка.
• Когда приложение находится в рабочей среде, требования исправить ошибки исходят от пользователей и начальства, а не от руководителя проекта и группы тестирования — а разгневанное начальство гораздо опаснее.
• В рабочей среде нет отладчика.
• В рабочей среде процесс развертывания планируется и координируется заблаговременно. Никто не разрешит вам отключить приложение на несколько минут, чтобы протестировать исправление.
• В среде разработки журналы сообщений обычно содержат гораздо более подробную информацию, чем в рабочей среде.
Некоторые из симптомов недостаточного планирования поддержки выглядят так:
• Большинство проблем требует привлечения разработчика.
• Отношения между командой разработчиков и службой поддержки весьма напряженные; разработчики считают, что в службе поддержки собрали одних идиотов.
• Служба поддержки ненавидит новое приложение.
• Команды архитекторов и разработчиков проводят много времени в рабочей среде.
• Приложение часто перезапускается для решения возникших проблем.
• Администраторам вечно не хватает времени для нормальной настройки системы, потому что они постоянно занимаются «тушением пожаров».
Чтобы ваше приложение успешно работало после того, как выйдет из рук разработчиков, вы должны:
• Понять, что разработка и поддержка требуют разных навыков.
• Как можно раньше вовлечь в проект руководителя службы технической поддержки.
• Сделать руководителя службы технической поддержки одной из центральных фигур проектной команды.
• Привлечь руководителя службы технической поддержки к планированию поддержки приложения.
Проектируйте продукт так, чтобы обучение персонала службы поддержки проходило с максимальной скоростью. Трассируемость, аудит и журналы играют в сопровождении чрезвычайно важную роль. Когда довольны администраторы системы, все остальные тоже довольны (особенно ваш начальник).
Мнчедизи Каспер (Mncedisi Kasper) — директор по технологии и стратегии в Open Xcellence ICT Solutions, южноафриканской компании, специализирующейся на интеграции корпоративных приложений и консультациях в области SAP (АВАР/XI).
Приготовьтесь выбрать два из трех
Билл де Ора
Иногда ввод некоторого ограничения или отказ от какого-либо свойства улучшает архитектуру, делает ее более простой и экономичной. Желательные свойства обычно группируются по три, но попытки описать и построить систему, обладающую всеми тремя свойствами, как правило, дают результат, посредственный во всех трех отношениях.
Знаменитый пример такого рода — теорема Брюэра, которая гласит, что для распределенной системы желательными являются три свойства — целостность (Consistency), доступность (Availability) и устойчивость к разделению (Partitioning tolerance) — и что достичь всех трех целей сразу невозможно. Попытки получить «все сразу» кардинально повышают затраты на разработку и, как правило, влекут за собой рост сложности, не приводя при этом к желаемому эффекту и реальному достижению бизнес-цели. Если данные должны быть распределенными и постоянно доступными, обеспечение целостности обходится все дороже и в конечном счете становится нереальным. Аналогичным образом, если система должна быть распределенной и целостной, обеспечение целостности
На этой странице вы можете бесплатно читать книгу 97 этюдов для архитекторов программных систем - Нил Форд бесплатно.
Похожие на 97 этюдов для архитекторов программных систем - Нил Форд книги
- Платформа J2Me - Автор неизвестен - Программирование