Для архитекторов ПО не существует ничего заведомо удобного и понятного. Каждое решение исходит из учета множества противоречащих друг другу факторов.
Если архитектор полагает, что обнаружил нечто бескомпромиссное, то, скорее всего, компромисс еще просто не выявлен.
Следствие 1
Архитектура — это нечто большее, чем простое сочетание структурных элементов, что находит отражение во Втором законе архитектуры программного обеспечения:
Почему важнее, чем как
Прежде всего авторы усвоили Первый закон архитектуры программного обеспечения, постоянно сталкиваясь с ним:
Все в архитектуре программного обеспечения соткано из компромиссов
В эволюционных архитектурах эту методику используют и для создания архитектурных функций пригодности, дающих объективную оценку целостности ряда архитектурных свойств. Эта оценка может включать в себя различные механизмы: например, системы показателей, юнит-тесты, системы отслеживания и хаос-инжиниринг. Скажем, в качестве важного архитектурного свойства архитектор задает время загрузки страницы. Чтобы позволить системе вносить изменения в страницу без ущерба для производительности, архитектурой создается функция пригодности в виде теста, замеряющего время загрузки для каждой страницы, а затем этот тест запускается для проекта как часть непрерывной интеграции. Благодаря этому архитекторы всегда в курсе состояния критически важных частей архитектуры, поскольку у них имеется механизм проверки для каждой такой части в форме функции пригодности.
Методики проектирования должны быть подобраны в соответствии с правилами архитектуры, подобно тому как в проблемных регионах при строительстве зданий учитываются особенности окружающей среды.
Активное развитие разработки программного обеспечения началось с выходом обновленной версии многих практических приемов XP в книге «Continuous Delivery» (издательство Addison-Wesley Professional) и привело к появлению DevOps.
Разработка архитектуры стала итеративным процессом из-за неизвестных неизвестностей, но Agile просто признает это и делает это быстрее.
Под процессом подразумевается формирование команд и управление ими, порядок проведения совещаний и организация повседневной работы, то есть все, что относится к специфике объединения людей и их взаимодействия. А под практикой проектирования ПО подразумевается деятельность, не связанная с процессом, но приносящая наглядную пользу. В качестве примера можно привести непрерывную интеграцию, которая не зависит от какого-либо конкретного процесса.
Появились причины отделить процесс разработки программного продукта от практики проектирования.
