97 этюдов для архитекторов программных систем
Шрифт:
Создание архитектуры программного обеспечения сводится к поиску наилучшего решения задачи при некоторых заданных ограничениях. Редко когда удается обеспечить выполнение всех требований и уложиться во все ограничения с первым же решением, которое пришло вам в голову. Обычно приходится идти на компромиссы, выбирая решение, лучше всего удовлетворяющее тем требованиям, которые определяются важнейшими приоритетами.
Если вы видите только одно решение текущей проблемы, это означает, что у вас отсутствует свобода выбора для поиска таких компромиссов. Вполне возможно, что это единственное решение окажется неудовлетворительным для некоторых заинтересованных
Такая ситуация крайне редко возникает из-за реального отсутствия альтернатив. Гораздо более вероятное объяснение — неопытность архитектора в предметной области конкретной задачи. Если вы знаете, что это относится к вам, не постесняйтесь обратиться за советом к кому-нибудь из более опытных в этом вопросе коллег.
Другое, более коварное проявление этой проблемы встречается при проектировании архитектуры «по привычке». Архитектор может иметь богатый опыт применения одного архитектурного стиля (например, трехуровневая система типа клиент-сервер), но ему не хватает знаний, чтобы определить, когда этот стиль неуместен. Если вы оказались в ситуации, когда решение известно вам сходу, без сопоставления с другими возможными вариантами, задержитесь, сделайте шаг назад и попытайтесь придумать другой способ решения той же задачи. Если это не получается, возможно, стоит обратиться за помощью.
Один мой друг работал техническим руководителем в небольшой, но быстро развивающейся интернет-компании. По мере роста числа пользователей начала возрастать и нагрузка на систему. Это привело к резкому падению производительности, и компания начала терять с таким трудом обретенных пользователей.
Начальник спросил его:
— Что мы можем сделать для улучшения производительности?
У моего друга уже был готов ответ:
— Купить более мощную машину!
— А что еще?
— М-м-м… Насколько я знаю, ничего.
Моего друга немедленно уволили. Разумеется, начальник был прав.
Биография автора приведена ранее.
Осознавайте последствия изменений
Дуг Кроуфорд
Хороший архитектор снижает сложность до минимума и может спроектировать решение, абстракции которого, с одной стороны, обеспечивают надежный фундамент, а с другой — достаточно прагматичны, чтобы пережить изменения.
Выдающийся архитектор понимает последствия изменений — не только в отдельных программных модулях, но также в отношениях между людьми и между системами.
Изменения могут проявляться в разных формах:
• Изменения функциональных требований
• Ужесточение требований к масштабируемости
• Модификация интерфейсов системы
• Приход и уход членов команды
• и так далее…
Масштаб и сложность изменений в программном проекте невозможно определить заранее. Бесполезно пытаться объехать каждую выбоину на дороге до того, как вы на нее наткнетесь. Но переживет проект очередное препятствие или нет, в большой степени зависит от архитектора.
Задача архитектора — не столько
Для примера возьмем распределенное решение, в котором задействовано несколько приложений, объединенных различным промежуточным программным обеспечением (middleware). Если набор зависимостей неверно определен или неточно представлен в визуальной модели, изменения бизнес-процесса могут привести к настоящему хаосу. Последствия изменений оказываются особенно серьезными, если изменения затрагивают модель данных или нарушают имеющиеся интерфейсы, а существующие долговыполняемые транзакции с отслеживанием состояния должны быть успешно завершены в старой версии процесса.
Пример может показаться излишне радикальным, но решения с высокой степенью интеграции в наше время применяются повсеместно. Это очевидно по ассортименту предлагаемых стандартов интеграции, инфраструктур и шаблонов. Чтобы обеспечить вашим клиентам нормальный уровень поддержки, крайне важно понимать последствия изменений в таких системах, частично лежащих за пределами вашей досягаемости.
К счастью, существует целый ряд инструментов и методов, позволяющих смягчить воздействие изменений:
• Вносите небольшие, поэтапные изменения
• Создавайте воспроизводимые тестовые сценарии и часто запускайте их
• Упрощайте построение тестовых сценариев
• Отслеживайте зависимости
• Действуйте и реагируйте систематично
• Автоматизируйте повторяющиеся задачи
Архитектор должен оценить воздействие изменений на различные аспекты масштаба проекта, времени и бюджета и быть готовым уделить больше внимания тем областям, которые способны оказать наиболее сильное влияние, став той самой «выбоиной на дороге». Оценка рисков — полезный инструмент для принятия решения о том, на что следует расходовать ваше драгоценное время.
Снижение сложности — важная задача, но низкая сложность не равнозначна простоте. Понимание возможных изменений и их влияния на решение оказывает неоценимую пользу в среднесрочной и долгосрочной перспективах.
Дуг Кроуфорд (Doug Crawford) руководит командой разработчиков промежуточного программного обеспечения для телекоммуникационной компании в Южной Африке. Последние 10 лет он с успехом совмещал несовместимое и принимал самое непосредственное участие в проектах по интеграции приложений в разнообразных отраслях: рекламе, банковском обслуживании крупного бизнеса, страховании и образовании.
Архитектор должен разбираться в оборудовании
Камал Викраманаяке
Для многих архитекторов тема планирования мощностей оборудования выходит за рамки их «зоны комфорта», однако она остается важной частью работы архитектора. Причины, по которым архитекторы часто забывают уделить должное внимание оборудованию, весьма разнообразны, но все они связаны большей частью с недопониманием и нечеткостью требований.
Главная причина заключается в том, что мы полностью концентрируемся на программной стороне и игнорируем аппаратные требования. Вдобавок языки высокого уровня и программные инфраструктуры (software frameworks) естественным образом изолируют нас от оборудования.