[2/2] Teaching Software Architecture Design - Building Intuition (Рубрика Architecture)
Продолжая первый пост с разбором whtepaper про обучение архитектуре, здесь я расскажу про оставшуюся часть статьи
Анализ гипотез по отношению к требованиям в итоге должен вести к
- Развитию инженерного подхода к принятию дизайн решений
- Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям
- Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна
Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт
- Они опираются на текущие данные и принимают решения в этом контексте
- При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше
- А это потребует принятия нового решения, что изменит старое Обычно такой процесс реализуется с использованием подходов RFC и ADR, где
- RFC - это request for comments или подход коммитетов к принятию решения
- ADR - это architecture decision record, что добавляется в список принятых архитектурных решений.
В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов
- Аргументы для анализа use cases Если предложенная гипотеза о декомпозиции помогает реализовать необходимое поведение для конкретного сценария, то студенты могут попробовать задать критические вопросы вида
- Какие исключения из шагов в сценарии делают его вклад в вариант использования недействительным?
- Есть ли какие-либо побочные эффекты предлагаемой архитектуры, которые отрицательно влияют на шаги или мешают им выполняться?
- Вносит ли предлагаемая архитектура отрицательный вклад в другие требования системы (варианты использования или требования к атрибутам качества)?
- Нарушаются ли какие-либо ограничения во время выполнения сценария или его исключений?
- Аргументы для анализа атрибутов качества Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход
- Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры.
- Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества. Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так
- Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества?
- Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе?
Авторы давали студентам дизайнить решения из разных индустрий, что приводило к тому, что баланс между атрибутами качества каждый раз был разный. Это позволило студентам научиться анализировать требования, выдвигать дизайн-гипотезы, а также составлять аргументацию в поддержку своих гипотез. В общем, цель развития интуиции при принятии дизайн-решений была достигнута.
P.S. Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:)
#Architecture #Software #Engineering #SelfDevelopment