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

Создание архитектуры как искусство баланса Рэнди Стаффорд

Соотнесите интересы сторон с техническими требованиями

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

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

Для примера возьмем инженерно-технический отдел организации, предоставляющей услуги по разработке программного обеспечения. Скорее всего, у этой организации существуют определенные приоритеты: соблюдение контрактных обязательств, получение дохода, поддержание хорошей репутации среди клиентов, снижение затрат и создание ценных технических активов. Эти бизнес-приоритеты преобразуются в приоритеты отдела: обеспечить функциональность, корректность и «атрибуты качества» разрабатываемого продукта, а также продуктивность команды разработки, устойчивость процесса разработки, возможность его аудита, адаптируемость и долговечность программных продуктов.

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

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

Говоря коротко, создание архитектуры программного продукта не ограничивается одними лишь техническими аспектами; в процессе работы необходимо также найти правильное соотношение технических требований и бизнес-требований всех заинтересованных сторон.

Биография автора приведена ранее.

Сделать наспех и сбежать — преступление Никлас Нильссон

Время близится к вечеру. Команда дружно корпит над новой функциональностью, запланированной для текущей итерации; кажется, даже воздух в комнате пульсирует в рабочем ритме. Однако Джон немного спешит: его ждет свидание. Впрочем, он успевает дописать свою часть кода, компилирует ее, регистрирует в системе управления исходным кодом — и поспешно уходит. Несколько минут спустя загорается «красный свет»: сборка приложения нарушена. У Джона не было времени на автоматизированные тесты, поэтому он поступил по принципу «сделать наспех и сбежать», из-за чего застопорилась работа всей команды.

Ситуация изменилась — рабочий ритм сбился. Теперь все знают, что при обновлении кода из системы контроля версий неработоспособный код окажется и на их локальных компьютерах, а поскольку для подготовки к предстоящей демонстрации команде предстоит интегрировать много кода, это становится серьезным препятствием. По сути дела, Джон поставил команде подножку — ведь интеграция станет возможна только после того, как кто-то потратит свое время на отмену его изменений.

Такая ситуация возникает до обидного часто. Сделать наспех и сбежать — преступление, поскольку в результате нарушается нормальный ход работы. Это печально распространенный среди разработчиков способ сэкономить немного времени лично для себя, в итоге потратив впустую чужое время, что служит проявлением прямого неуважения к другим людям. И все же это происходит повсеместно. Почему? Обычно потому, что полноценная сборка системы или проведение тестов занимает слишком много времени.

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

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

Никлас Нильссон (Niclas Nilsson) — консультант и преподаватель в области разработки программного обеспечения, а также писатель, глубоко увлеченный искусством программирования, ценитель хорошей архитектуры и дизайна. Является одним из соучредителей factor10 и редактором материалов в сообществе архитекторов ПО на сайте InfoQ.

Решений может быть несколько Кейт Брайтуэйт

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

В технической области единообразие можно ввести принудительно. И для нас это весьма удобно. Однако в сфере бизнеса в игру врывается противоречивый, многогранный, неформальный, хлопотный реальный мир. Что еще хуже, бизнесу приходится иметь дело даже не с реальным миром, а с мнениями людей о тех или иных аспектах ситуаций в тех или иных частях этого мира. Можно, конечно, попытаться отнестись к этой сфере как к технической и внедрить единое решение в приказном порядке. Однако реальность неформально определяется как «то, что не исчезает, когда в него перестаешь верить» (Филип К. Дик), и по мере развития бизнеса проблемы всегда возвращаются. Так возникают команды, занимающиеся корпоративными данными и тому подобным, которые тратят все свое (очень дорогое) время на обуздание экзистенциального ужаса посредством жонглирования DTD. [9]

9

DTD (Document Type Definition) — определение типа документа — преамбула документа, определяющая в языках структурной разметки данных (SGML, XML) состав и структуру документа. — Примеч. ред.

Время отклика подобных систем обычно оказывается неудовлетворительным с точки зрения заказчика.

Почему бы не принять реальность непоследовательного мира и не допустить существование нескольких несогласованных, перекрывающихся представлений, служб, решений? Да, технический специалист в каждом из нас, услышав такое предложение, съеживается от ужаса. Мы сразу представляем себе кошмарные сценарии: несогласованные обновления, лишние затраты на сопровождение, клубки зависимостей, которыми приходится управлять… Но давайте позаимствуем полезный опыт из мира хранения данных. Витрины данных (data marts) часто денормализуются (в реляционном смысле), в них произвольно смешиваются импортированные и вычисленные значения, а представления данных сильно отличаются от представлений данных в исходных базах данных. И при этом от наличия у витрины данных нефункциональных свойств никакой катастрофы не происходит. На границе двух совершенно разных миров — как правило, операций с данными и аналитической обработки с характерными для них различиями в частоте обновления и выборки, в пропускной способности, в периодичности изменений структуры и, возможно, даже в объемах — находится ETL-процесс. [10] В этом ключ к задаче: достаточно сильные различия в нефункциональных свойствах системы формируют границу, через которую удается организовать практическое управление несогласованными представлениями.

10

ETL (Extract, Transform, Load — извлечение, преобразование, загрузка) — один из основных процессов в управлении хранилищами данных (см. — Примеч. ред.

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

Биография автора приведена ранее.

Всем заправляет бизнес Дэйв Мурхед