Помоги проекту - поделись книгой:
Ответственное руководство важнее внешнего впечатления
Когда архитектор приступает к проекту, у него появляется понятное желание «показать себя». Назначение на должность архитектора программного обеспечения обычно свидетельствует о доверии к технической компетентности специалиста со стороны компании; естественно, архитектор желает как можно скорее показать, что он заслуживает этого доверия. К сожалению, некоторые из нас ошибочно полагают, что для этого следует «представить себя во всей красе» — удивить, если не оглушить группу своей технической гениальностью.
Умение произвести впечатление на аудиторию играет важную роль в маркетинге, но отрицательно сказывается на руководстве программным проектом. Архитектор должен завоевать уважение своей команды ответственным подходом к руководству и хорошим пониманием технической и предметной областей решаемой задачи.
Ответственное руководство — вот достойная роль для архитектора. Архитектор должен действовать в интересах заказчика, а не потворствовать капризам своего эго.
Деятельность архитектора программного обеспечения направлена на удовлетворение потребностей пользователей чаще всего на основании указаний от тех, кто разбирается в предметной области лучше него. Успешная разработка ведет к поиску компромиссов между затратами/сложностью реализации и временем/рабочей силой, доступными для выполнения проекта.
Время и затрачиваемые усилия — ресурсы, принадлежащие компании; архитектор должен управлять ими добросовестно, без скрытых попыток реализовать собственные цели. Чрезмерно сложные системы на базе новомодных инфраструктур или технологий редко обходятся без дополнительных затрат со стороны компании. Архитектору, словно инвестиционному брокеру, доверены деньги клиентов — и при этом предполагается, что его работа обеспечит приемлемую окупаемость инвестиций.
Управлять со всей возможной ответственностью важнее, чем производить внешнее впечатление; никогда не забывайте, что вы распоряжаетесь деньгами других людей.
У программной архитектуры есть этические аспекты
Этический аспект программного обеспечения становится очевидным, когда речь заходит о гражданских правах, хищении личных данных или вредоносных программах. Однако он проявляется и в менее экзотических обстоятельствах. Успешно работающие программы влияют на жизнь тысяч, а то и миллионов людей. Их влияние может быть как положительным, так и отрицательным. Программы способны улучшить или ухудшить нашу жизнь — пусть даже в незначительной степени.
Каждый раз, когда я принимаю решение относительно поведения программы, я в действительности решаю, что смогут и что не смогут делать ее пользователи. Причем принятое решение гораздо более жестко, чем законодательство: не существует апелляционного суда, в котором можно было бы опротестовать выбор обязательных для заполнения полей или строгую последовательность операций.
На эту проблему можно взглянуть и с точки зрения эффекта масштаба. Вспомните истории о последних интернет-червях или фильмах-блокбастерах. Наверняка вам встречались подсчеты того, сколько рабочих часов было потеряно из-за них в масштабах страны. Всегда можно найти какого-нибудь аналитика с оценками неслыханного ущерба, нанесенного чем-нибудь, способным отвлечь человека от рабочего стола. Мораль этой истории вовсе не в обличении математического невежества прессы и дешевой погони за сенсациями. В действительности речь здесь идет о том эффекте, который могут дать маленькие числа в большом масштабе.
Представьте себе, что вы должны принять решение относительно некоторой функции. Есть два варианта реализации: простой, требующий одного дня работы, и сложный, который отнимет неделю. В простом варианте приходится вводить четыре новых обязательных поля, а в сложном программе хватит ума на то, чтобы обработать неполные данные. Какой способ вам следует выбрать?
Обязательные поля выглядят довольно безобидно, но с ними вы навязываете свою волю пользователям, заставляя их собирать дополнительную информацию до начала работы. А это часто означает, что данные придется записывать на бумажках, чтобы собрать их в одном месте и ввести в систему единовременно. Все это ведет к потере данных и задержкам, а также вызывает раздражение у пользователей.
Рассмотрим такую аналогию: допустим, мне нужно прикрепить на здание вывеску. Можно ли смонтировать ее на высоте 1,8 м, заставляя тем самым пешеходов нырять под нее или обходить ее стороной? Конечно, мне будет проще обойтись без лестниц и строительных лесов, при этом вывеска даже не будет полностью перекрывать движение. Я экономлю час на установке ценой двух секунд, которые я отнимаю у каждого пешехода, проходящего мимо моего магазина. С течением времени сумма этих двухсекундных потерь намного превысит сэкономленный мною час.
Неэтично усложнять жизнь другим (даже ненамного) только для того, чтобы немного упростить ее для себя. Успешные программы влияют на жизнь миллионов людей, но каждое принятое вами решение фактически навязывает вашу волю пользователям. Всегда помните о том, что ваши решения повлияют на жизнь этих людей. Будьте готовы взять на себя дополнительную ношу, чтобы снять часть груза с ваших пользователей.
Небоскребы не масштабируются
Разработку программных продуктов часто сравнивают со строительством небоскребов, дамб и дорог. В некоторых важных аспектах это уместное сравнение.
Самая трудная часть строительства не проектирование здания, которое будет стоять на своем месте после завершения, а проработка процесса строительства. Этот процесс начнется с пустой площадки и завершится готовым зданием. За это время каждый рабочий должен иметь возможность применить свои профессиональные навыки, а частично возведенное строение должно оставаться устойчивым. Мы можем извлечь из этой аналогии полезный урок в том, что касается развертывания больших интегрированных систем. (А к категории «интегрированных» относятся практически все корпоративные и веб-приложения!) Традиционное развертывание по схеме «Большого взрыва» выглядит так, словно вы привезли на пустырь груду балок и брусьев, подбросили их в воздух и ожидаете, что они сами сложатся в форме здания.
Вместо этого следует планировать развертывание по одному компоненту. Такой подход обладает двумя заметными преимуществами как при замене существующей системы, так и при строительстве с нуля.
Во-первых, при развертывании программного продукта мы попадаем в зону кумулятивного технического риска, воплощенного в программном коде. При последовательном покомпонентном развертывании этот технический риск распределяется по более длительному промежутку времени. Каждый компонент получает самостоятельный шанс вызвать сбой при вводе в эксплуатацию, что позволяет нам доводить компоненты до ума по отдельности.
Во-вторых, последовательное развертывание заставляет нас создавать четко определенные интерфейсы между компонентами. Развертывание одного компонента новой системы часто подразумевает его обратную интеграцию со старой системой. Следовательно, к моменту завершения развертывания каждый компонент успеет поработать с двумя разными системами: исходной и замещающей. Тем самым покомпонентное развертывание автоматически улучшает возможность повторного использования компонентов. На практике это приводит также к увеличению сцепления (coherence) и уменьшению связанности (coupling) системы.
С другой стороны, в ряде важных аспектов аналогия со строительством не работает. В частности, материальность реального мира усиливает роль предварительного планирования, заставляя нас использовать метод «водопада». В конце концов, никто не начинает строить небоскреб, не зная заранее, сколько места он займет и сколько этажей в нем будет. Добавлять этажи к существующему зданию слишком дорого и рискованно, поэтому мы стараемся избегать таких крайностей. Местонахождение или высота единожды спроектированного небоскреба уже не должны изменяться. Небоскребы не масштабируются.
Мы не можем с легкостью расширить дорогу новыми полосами, но знаем, как легко включить в программу новые функции. Это не дефект процесса разработки, а достоинство той среды, в которой мы работаем. Ничто не мешает нам выпустить приложение с минимальной функциональностью, если пользователи достаточно ценят эти функции, чтобы заплатить за них. На практике чем раньше вы выпустите свое приложение, тем выше будет чистая стоимость итогового продукта.
На первый взгляд ранний выпуск противоречит подходу «пошагового развертывания», но в действительности они весьма хорошо сочетаются. Ранний выпуск отдельных компонентов означает, что каждый компонент может проходить итеративную разработку независимо от других компонентов. Более того, этот подход заставит вас проработать такие проблемные вопросы, как постоянная доступность в ходе развертывания и контроль версий протоколов.
Нечасто встречаются методы, обеспечивающие более высокую коммерческую ценность в сочетании с улучшением архитектурных качеств, но раннее развертывание отдельных компонентов обладает обоими достоинствами.
Неоднородность побеждает
Естественная эволюция компьютерных технологий привела к важным изменениям в тех инструментах, которые используют архитекторы для создания компьютерных систем. Эти изменения воскресили интерес к многоязыковому программированию, то есть к использованию нескольких языков в качестве основных при реализации программной системы.
Концепция многоязыкового программирования не нова; характерным примером из прошлого служат системы, в которых клиентская часть написана на Visual Basic и использует серверную часть на базе объектов СОМ, написанных на C++. По сути дела эта архитектура эффективно использовала сильные стороны каждого из упомянутых языков в зените их популярности.
Какие же перемены возродили интерес к многоязыковому программированию?
Новые технические стандарты в сочетании с постоянным ростом ресурсов — пропускной способности каналов и вычислительных мощностей — сделали возможным реальное использование текстовых протоколов. Те времена, когда эффективные распределенные системы были возможны лишь при использовании хитроумных двоичных протоколов, остались в прошлом. Возможность удаленного взаимодействия на текстовом уровне появилась вместе с веб-службами на базе XML/SOAP и продолжает развиваться в направлении архитектурных стилей REST и других вспомогательных (но не менее важных) протоколов типа Atom и ХМРР.
Благодаря этому новому поколению технологий у нас есть гораздо больше возможностей для гетерогенной разработки, чем когда-либо прежде, просто потому, что полезная информация теперь представляет собой отформатированный текст, который можно генерировать и обрабатывать универсальными средствами. Гетерогенная разработка позволяет для каждой конкретной задачи выбирать наиболее подходящий инструмент, а способность систем взаимодействовать на текстовом уровне сметает многие прежние преграды.
Теперь архитекторы могут объединять специализированные мощные инструменты, позволяющие вести речь уже не о способности применить подходящий язык, а о способности применить правильную парадигму. Языки программирования поддерживают различные парадигмы, некоторые из которых объектно-ориентированные, а другие функциональные или ориентированные на параллельное программирование. Для конкретных задач или предметных областей одни из этих парадигм подойдут идеально, а другие окажутся несоответствующими. Однако в наши дни эти нетрадиционные (и на первый взгляд разнородные) инструменты объединяются в элегантные гибридные решения гораздо легче, чем прежде.
Эффект этих изменений уже виден в комбинаторном увеличении сложности архитектурной топологии современных программных систем. Этот аспект — не столько отражение присущей им разнородности, сколько признак новых возможностей.
Наличие выбора не всегда полезно, но в данном случае оно является «меньшим из зол» в контексте современных программных архитектур. Наша отрасль имеет дело с очень серьезными задачами,[20] поэтому нам необходимы все возможности взаимодействия, которые только можно обеспечить, особенно если задействованные в настоящий момент платформы не очень хорошо подходят для решения этих задач.[21]
В наши дни работа архитектора стала еще более сложной из-за того, что границы технологий трещат под напором новых возможностей. Примите этот вызов, учитесь мыслить широко и обратите богатство возможностей в свою пользу: неоднородность побеждает.
Не забывайте о производительности
Представьте себе автомобиль — просторный, удобный, экономичный, недорогой и утилизируемый на 98 %. Хотите такой? Конечно. Кто угодно захочет. Ах, да, единственная проблема: его максимальная скорость составляет 10 км/ч. Не передумали? Этот маленький пример наглядно показывает, что производительность так же важна, как и любой другой критерий.
Многие архитекторы ставят производительность на последнее место в своих списках — возможно, потому, что компьютеры обрабатывают данные несопоставимо быстрее своих пользователей, и архитектору кажется, что скорость системы окажется приемлемой. А если современным системам не хватит быстродействия, обо всем позаботится закон Мура. Однако скорость работы оборудования — лишь один из аспектов системы.
Производительность иногда рассматривается просто как промежуток времени, который нужен системе, чтобы отреагировать на введенные пользователем данные. Но архитекторы систем должны учитывать разнообразные аспекты производительности, включая производительность труда аналитиков и программистов, реализующих дизайн, производительность общения пользователя с системой, а также быстродействие неинтерактивных компонентов.
Производительность труда людей, строящих систему, часто называется продуктивностью. Этот показатель весьма важен, поскольку он непосредственно отражается на затратах и графике проекта. Команда, сдающая проекты с большим опозданием и перерасходом средств, обречена на неприятные разговоры с руководством. Правильный выбор инструментов и готовых компонентов может радикально повлиять на то, как быстро система будет построена и начнет приносить прибыль.
Производительность взаимодействий с пользователем играет решающую роль в том, как пользователи примут систему. В этот аспект производительности вносят свой вклад многие факторы системной архитектуры. Самым очевидным примером, пожалуй, является время отклика, однако это далеко не единственный показатель. Не менее важны интуитивная понятность интерфейса и количество операций, которые должен выполнить пользователь, чтобы достичь своей цели; и то, и другое напрямую влияет на производительность.
Хорошая спецификация системы определяет не столько время отклика само по себе, сколько время выполнения задания. Оно определяется как промежуток времени, необходимый для решения задачи из конкретной предметной области, включая все взаимодействия пользователя с системой. Кроме времени отклика в эту характеристику входят время размышления оператора и время ввода данных оператором — величины, находящиеся вне сферы контроля системы. Однако включение этих метрик способствует качественному проектированию пользовательского интерфейса. Уделив внимание способу представления информации и количеству операций, необходимых для решения задачи, вы в конечном итоге улучшите производительность человека-оператора.
Производительность неинтерактивных компонентов не менее важна для успеха системы. Например, если на выполнение еженощно запускаемых пакетных заданий требуется более 24 часов, система становится неработоспособной. Производительность компонентов аварийного восстановления также относится к числу критических факторов. Сколько времени потребуется для восстановления работоспособности системы и продолжения нормальной работы, если одна из частей системы полностью вышла из строя?
Анализируя реализацию и рабочий режим успешной системы, архитекторы и проектировщики всегда должны обращать самое пристальное внимание на производительность.
Проектирование в пустоте
Система состоит из взаимозависимых программных элементов. Организационная структура этих программных элементов вместе с объединяющими их отношениями называется
Одна маленькая стрелка может означать: «Синхронный запрос/ответ в формате SOAP-XML через HTTP». Для одного элемента диаграммы получается слишком много информации. Места для полной записи обычно не хватает, поэтому мы помечаем стрелку надписью «XML через HTTP» (с точки зрения внутренней реализации) или «Поиск по коду товара» (с точки зрения внешних пользователей).
Стрелка, связывающая программы, выглядит как непосредственный контакт, но в действительности им не является. Пустота между прямоугольниками заполнена аппаратными и программными компонентами. В частности, здесь могут находиться:
• Сетевые карты
• Сетевые коммутаторы
• Брандмауэры
• Системы обнаружения и предотвращения вторжений (IDS/IPS)
• Брокеры или очереди сообщений
• Механизмы преобразования XML
• Серверы FTP
• Зонные таблицы
• Кольца SoNET
• Шлюзы MPLS
• Магистральные линии
• Океаны
• Рыболовные траулеры, повреждающие донные кабели
Между программными элементами А и Б всегда находятся четыре-пять компьютеров, на которых работают программы коммутации пакетов, анализа трафика, маршрутизации, анализа угроз и т. п. И вы как архитектор, связывающий эти программные модули друг с другом, должны учитывать существование этой промежуточной среды.
Однажды я видел стрелку с надписью «Исполнение». Один сервер был установлен в компании моего клиента, второй находился совершенно в другом месте. Эта жизненно важная для клиента стрелка запускала цепочку событий, которая больше напоминала игру «Мышеловка», нежели единый интерфейс. Сообщения передавались брокерам, сохраняющим их в файлах, которые периодически запускаемыми заданиями загружались на FTP… и т. д. Этот «интерфейс» включал в себя более 20 этапов.
Необходимо хорошо понимать, какая статическая и динамическая нагрузка ложится на каждую стрелку. Рядом с «SOAP-XML через HTTP» около стрелки стоило бы написать также: «С каждым запросом HTTP принимается одно обращение, с каждым ответом HTTP возвращается один ответ. Ожидается до 100 запросов в секунду, ответ в 99,999 % случаев должен выдаваться менее чем за 250 мс».
Но и это еще не все, что необходимо знать об этой стрелке:
• Что если вызывающая сторона обращается по ней слишком часто? Как должен действовать получатель — игнорировать запросы, вежливо отказывать или по возможности стараться их обработать?
• Что делать вызывающей стороне, если обработка запроса заняла более 250 мс? Повторить попытку? Немного подождать? Решить, что на стороне получателя произошел сбой, и продолжить работу без этой функции?
• Что произойдет, если вызывающая сторона отправила запрос по протоколу версии 1.0, а получила ответ в версии 1.1? А если вместо XML был получен код HTML? Или файл в формате MP3 вместо XML-файла?
• Что произойдет, если одна из сторон интерфейса станет временно недоступной?
Ответы на эти вопросы представляют собой суть проектирования «в пустом пространстве» диаграмм.
Изучите профессиональный жаргон
В любой профессии существует свой жаргон, повышающий эффективность общения представителей этой профессии. Адвокаты говорят друг с другом о Habeas Corpus, Voir Dire и Venire, плотники — о соединениях встык и внахлест и о пропитках, а архитекторы ПО — о ROA, двухэтапном представлении и супертипах уровней…Минуточку… о чем, простите?..
Очень важно, чтобы архитекторы ПО независимо от платформы, на которой они работают, располагали эффективными средствами общения друг с другом. Одним из таких средств являются архитектурные шаблоны и шаблоны проектирования. Чтобы эффективно работать в качестве архитектора, необходимо понимать базовые архитектурные шаблоны и шаблоны проектирования, различать их в коде, знать, когда они применяются, и уметь использовать их в разговоре с другими архитекторами и разработчиками.
Архитектурные шаблоны и шаблоны проектирования можно разделить на четыре основные категории: шаблоны корпоративного уровня, шаблоны уровня приложения, шаблоны интеграции и шаблоны проектирования. Эти категории обычно определяются уровнем абстракции шаблона в общей архитектуре. Шаблоны корпоративного уровня относятся к высокоуровневой архитектуре, тогда как шаблоны проектирования относятся к структуре и поведению отдельных компонентов общей архитектуры.
Шаблоны корпоративного уровня определяют «каркас» высокоуровневой архитектуры. К числу самых распространенных архитектурных шаблонов относятся архитектура, управляемая событиями (EDA, Event-Driven Architecture), сервис-ориентированная архитектура (SOA, Service-Oriented Architecture), ресурсно-ориентированная архитектура (ROA, Resource-Oriented Architecture) и конвейерная архитектура (pipeline architecture).
Шаблоны уровня приложения описывают дизайн приложения или подсистемы в контексте более крупной корпоративной архитектуры. К этой категории относятся хорошо известные шаблоны J2EE (например, Session Facade (фасад сессии) и Transfer Object (объект перемещения)), а также шаблоны, описанные в книге Мартина Фаулера (Martin Fowler) «Patterns of Enterprise Application Architecture»[22] (Addison-Wesley Professional).
Шаблоны интеграции играют важную роль в проектировании и описании концепций, связанных тем, как компоненты, приложения и подсистемы совместно используют информацию и функциональность. Вот некоторые примеры шаблонов интеграции: общий доступ к файлам, удаленные вызовы процедур, различные шаблоны передачи сообщений. Описания этих шаблонов см.
Знание основных шаблонов из книги «банды четырех» «Design Patterns: Elements of Reusable Object-Oriented Software»[23] (Addison-Wesley Professional) обязательно для каждого архитектора. На первый взгляд может показаться, что эти шаблоны относятся к слишком низкому для архитектора программных продуктов уровню, однако они — часть лексикона, позволяющего архитекторам и разработчикам эффективно общаться.
Архитектор должен также знать и понимать суть различных антипаттернов.
Поделиться книгой: