Как архитектурное проектирование выполняется в динамичной среде?

59

Я прочитал Принципы Agile Architect , где они определили следующие принципы:

Принцип # 1 Команды, которые кодируют систему, проектируют систему.
Принцип № 2 Создайте простейшую архитектуру, которая может работать.
Принцип № 3 Если есть сомнения, закодируйте его.
Принцип № 4 Они строят это, они проверяют это.
Принцип № 5 Чем больше система, тем длиннее взлетно-посадочная полоса.
Принцип № 6 Архитектура системы - это ролевое сотрудничество.
Принцип № 7 Нет монополии на инновации.

В документе говорится, что большая часть проектирования архитектуры выполняется на этапе кодирования, и только до этого проектирование системы. Это хорошо.

Итак, как выполняется проектирование системы? Используете UML? Или документ, который определяет интерфейсы и основные блоки? Может быть, что-то еще?

BЈовић
источник
11
Вы не «делаете дизайн» в UML. Вы делаете дизайн, а затем вы используете UML, чтобы записать его или сообщить об этом.
tdammers
4
@tdammers: если быть точным, вы пытаетесь использовать UML, чтобы записать его, и заметите, что UML недостаточно.
Док Браун

Ответы:

77

Отказ от ответственности: я являюсь архитектором в гибкой среде , но, как Мольтке говорит: «Ни один план сражения не выдерживает контакт с врагом». Другими словами, практичность означает, что точная буква руководящих принципов не всегда может соблюдаться.

Большинство пунктов, поднятых выше, соблюдаются как можно лучше. Однако принципу 1 (команды, которые кодируют систему, разрабатывают систему) действительно трудно следовать, когда команда состоит из десятков (или сотен) разработчиков, разбросанных по разным континентам и часовым поясам . Это не имеет ничего общего с навыками или отношениями разработчиков, а скорее с их материально-технической проблемой, связанной с тем, чтобы собирать требования от клиентов и понимать существующие сложные системы.

Итак, как выполняется проектирование системы? Используете UML? Или документ, который определяет интерфейсы и основные блоки? Может быть, что-то еще?

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

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

  1. Расширенные требования и определение области применения. К ним относятся сценарии использования или пользовательские истории, которые отражают бизнес-требования более высокого уровня. Мне лично нравится использовать RFC 2119 для нефункциональных требований. Дизайн основан и прослежен до них. Хотя это может не соответствовать общему определению дизайна, они часто так же важны.
  2. Обзор, состоящий из высокоуровневой схемы сети или компонентов и страницы текста. Это для очень широкой аудитории, от высшего руководства до разработчиков и QA. Это редко использует UML или определенные обозначения из-за широкой аудитории.
  3. Подробности для отдельных компонентов, часто с акцентом на интерфейсах или API между ними, как упомянуто выше. Интерфейсы могут быть указаны как сигнатуры методов на целевом языке с подробностями предусловия и постусловия. Компоненты могут иметь сетевые диаграммы, например, показывающие расположение виртуальных машин в облаке или центре обработки данных и их сетевые схемы. Реляционные базы данных обычно имеют диаграммы Entity-Relationship.
  4. Список архитектурных рисков и их снижение, если известно. Как и требования, они демонстрируют проектные решения и компромиссы.

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

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

Актон
источник
3
Это отличный ответ на вопрос о том, какой должна быть роль архитектора в Agile команде, однако на самом деле он не отвечает на вопрос о том, что такое дизайн системы до начала спринтовой разработки и о лучших методах ее выполнения.
maple_shaft
@maple_shaft Я расширил свой ответ, чтобы больше сосредоточиться на дизайне.
Актон
3
Что бы это ни стоило, для другого архитектора, который несколько лет работал в гибких средах в крупных многонациональных средах, это очень актуально.
Рекс М
12

Отказ от ответственности: я не проворный тренер / архитектор - это то, что я видел в гибких проектах, над которыми я работал, и я думаю, что это работает хорошо.

Я не думаю, что Agile определил, как вы делаете архитектуру - agile фокусируется на методологиях и практиках разработки. UML, с другой стороны, является просто языком для передачи вашей архитектуры, который находится за пределами гибкости (вы используете его, если он подходит вашему проекту и вашей команде).

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

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

Рупеш Шеной
источник
0

Выполняя тестовую разработку, вы создаете тестовый код, который тестирует ваши модули изолированно (= как можно более независимо от других модулей)

Чтобы упростить создание кода тестирования, вы вводите интерфейсы для других модулей, которые могут быть легко смоделированы.

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

На мой взгляд, ТДД это также архитектурная работа.

k3b
источник
Да, TDD - это архитектурная работа, но на программных компонентах. Мой вопрос действительно заключается в том, как архитектура крупномасштабного проекта создается с использованием гибких принципов.
BЈовић