This repository includes the most valuable quotes (in my mind) from "Building Evolutionary Architectures: Support Constant Change" book by Neal Ford, Rebecca Parsons, and Patrick Kua.
All rights are reserved by Robert Neal Ford, Rebecca Parsons, and Patrick Kua and publisher "Piter".
Main language is Russian 🇷🇺
Quotes from next sections were presented:
- Introduction
- Software Architecture
- Fitness Functions
- Engineering Incremental Change
- Architectural Coupling
- Building Evolvable Architectures
- Evolutionary Architecture Pitfalls and Antipatterns
- Putting Evolutionary Architecture into Practice
Долгое время разработчики программного обеспечения придерживались мнения, что архитектуру программного обеспечения следует разрабатывать до написания первой строки кода. Под влиянием строительной отрасли считалось, что признаком успешной архитектуры программного обеспечения было то, что в ней не надо ничего менять в процессе разработки, это часто было связано с высокими затратами на переделку архитектуры. В дальнейшем с появлением методов гибкого программного обеспечения такое представление об архитектуре изменилось. Метод заранее спланированной архитектуры основывался на том, что установленные требования не должны были меняться до написания кода, что приводило к поэтапному (или каскадному) методу проектирования, в котором за установленными требованиями следовала разработка архитектуры, а за ней, в свою очередь, следовала разработка программного обеспечения. Однако динамично меняющийся мир поставил под сомнение саму идею неизменности требований, так как изменения требований оказались просто необходимы для ведения бизнеса в современном мире и обеспечивали планирование проекта, позволяющее вносить контролируемые изменения.
Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях.
В организациях с функциональными «анклавами», которые существуют в полном отрыве от других участков, руководство разделяет команды в угоду отделу персонала, не обращая особого внимания на инженерную эффективность. Несмотря на то что каждая команда может хорошо справляться со своей частью проекта (например, с построением экрана, добавлением интерфейса для прикладных программ или сервисами в серверной части системы, с разработкой нового механизма хранения данных), для того чтобы создать новую бизнес-возможность или функцию, все эти команды должны работать совместно. Команды обычно оптимизируют эффективность для выполнения срочных задач, а не для достижения более абстрактных, стратегических бизнес-целей, особенно находясь под давлением графика. Вместо сквозной разработки функции команды часто направляют свои усилия на разработку компонентов, которые могут или не могут хорошо работать друг с другом. В таком организационном разделении функция, зависящая от всех трех команд, занимает больше времени, поскольку каждая команда работает над своим компонентом в разное время. Например, рассмотрим распространенное в бизнес-среде обновление страницы каталога. Это изменение ведет за собой изменения пользовательского интерфейса, бизнес-правил и схемы базы данных. Если каждая команда работает в своем собственном «анклаве», они должны координировать графики работ, увеличивая время, необходимое для реализации разрабатываемой функции. Это удачный пример того, как структура команд может влиять на архитектуру и способность эволюционировать. Как отмечает в этой статье Конвей, всякий раз при делегировании работ чей-то круг обязанностей сужается, при этом также сужается класс допустимых вариантов проектирования. Иначе говоря, сложно что-то менять, если это что-то принадлежит кому-то еще. Архитекторы должны обращать внимание на то, как работа делится и передается в группы для согласования целей архитектуры со структурой команд.
Структура команды должна выглядеть как целевая архитектура. Тогда ее будет проще достичь.
Система никогда не является суммой ее частей. Она является продуктом взаимодействий ее частей. — Д-р Рассел Л. Акофф (Dr. Russel Ackoff)
Проверка производительности должна проводиться на ранней стадии и достаточно часто, особенно при установлении точек перегиба, когда производительность сильно меняется (обычно в худшую сторону) из-за обновления кода.
Архитектура с эволюционным развитием поддерживает управляемые, инкрементные изменения в нескольких областях.
Разработчики не могут судить о долговременной жизнеспособности любой архитектуры, пока не пройдут успешно этапы проектирования, реализации, обновления и неизбежных изменений.
Процесс разработки гибкого программного обеспечения научил нас, что чем раньше будет обнаружена проблема, тем меньше усилий потребуется для ее разрешения.
В книге Бережливое предприятие Барри O’Рэйлли (Lean Enterprise, Barry O’Reilly, 2014) описывает современный процесс развития на основе гипотез. В этом процессе вместо сбора формальных требований и траты времени и ресурсов для встраивания функций в приложения команды должны использовать научный метод. После того как команда создала версию минимально жизнеспособного приложения (нового или в результате проведения обслуживания существующего приложения), они могут в процессе обдумывания новой функции создавать гипотезы, а не устанавливать требования. Гипотезы, лежащие в основе метода разработки, формулируются для проверки того, какие эксперименты могут получить требуемые результаты и какие нарушения гипотез имеют значение для разработки будущего приложения.
Механизмом, управляющим методами динамичного программного обеспечения, является вложенный контур обратной связи: тестирование, непрерывная интеграция, итерации и т. п. Часть цепи обратной связи, которая объединяет конечных пользователей приложения, использует команды, работа которых скрыта от конечных пользователей. Используя разработку, основанную на гипотезах, мы можем беспрепятственно включать пользователей в процесс разработки и на основе их поведения строить то, что действительно ценно.
Как упоминается в главе 8, при переходе с монолитной архитектуры на архитектуру с большим уровнем детализации начинать следует с меньшего количества более крупных сервисов. При построении архитектуры микросервисов с нуля разработчики должны быть внимательны при ограничении размера сервиса и контекстов данных. Но не следует воспринимать название микросервисов слишком буквально, каждый сервис не должен быть маленьким, он должен быть способным захватывать полезный ограниченный контекст.
Техники: 1. Определить области, затрагиваемые эволюционным развитием; 2. Определить для каждой области функцию(-и) пригодности; 3. Использовать конвейер развертывания для автоматизации функций пригодности
Пакет программного обеспечения часто приводит к самым тяжелым проблемам в отношении связанности. Вообще, эта система непрозрачна при использовании разработчиками для интеграции API. К сожалению, API страдает от проблем, описанных в разделе «Антипаттерн: ловушка на последних 10 %» на с. 206, предоставляя при этом разработчикам достаточную степень универсальности, чтобы завершить полезную работу.
С помощью ограничения возможности неожиданных изменений мы контролируем большое число факторов, которые делают систему хрупкой.
Неизменная инфраструктура следует нашей рекомендации убрать ненужные переменные. Построение программного обеспечения, которое эволюционирует, означает управление как можно большим числом неизвестных факторов
Сделать как можно больше решений обратимыми (без чрезмерного проектирования).
…есть известное знаемое, то есть вещи, о которых мы знаем, что мы о них знаем. Мы знаем также, что есть известное незнаемое, то есть, говоря иначе, мы знаем, что есть вещи, о которых мы не знаем. Но есть также неизвестное незнаемое — те вещи, о которых мы не знаем, что мы о них не знаем
Все архитектуры из-за неизвестных неизвестных становятся итеративными; гибкие компании просто распознали и сделали это раньше.
Одним из способов, часто используемым разработчиками для изоляции от изменений, является уровень защиты от повреждений (anticorruption layer).
Гибкие компании разработчиков оценили принцип последнего ответственного момента при принятии решений, который используется для противодействия распространенной угрозе в проектах, связанной со слишком ранним приобретением сложных систем.
Воспользуйтесь шаблонами сервисов, чтобы связать вместе надлежащие части архитектуры — элементы инфраструктуры, которые дают возможность командам воспользоваться преимуществами связанности.
Облачные среды сделали жертвенную архитектуру еще более привлекательной. Если у разработчиков есть проект, который необходимо испытать, то построение первоначальной версии в облаке значительно сокращает ресурсы, требуемые для релиза программного обеспечения. Если проект успешный, разработчики архитектуры могут позволить себе потратить определенное время, чтобы построить более подходящую архитектуру. Если разработчики заботятся об уровнях защиты от повреждений и других практиках эволюционирующей архитектуры, они могут уменьшить сложности миграции
По мере того как разработчики реконструируют архитектуру, их первым шагом должно быть удаление исторически сложившихся компромиссов проектирования, проявляющихся как технический долг.
Разработчики архитектуры делают общее различие между библиотеками и фреймворками, говоря, что «разработчик вызывает библиотеку, тогда как фреймворк вызывает разработчика».
Некоторые крупные предприятия приобретают программное обеспечение Планирование ресурсов предприятия (ERP — Enterprise Resource Planning) для решения распространенных бизнес-задач, таких как ведение учета, управление инвентаризацией и другие рутинные операции. Это работает, если компании готовы сгибать свои бизнес-процессы и другие решения для того, чтобы приспособить этот инструмент, и может быть использовано стратегически, когда разработчики архитектуры понимают ограничения и преимущества.
С точки зрения практического управления в крупных организациях оказалось, что модель управление «золотой середины» (Goldilocks Governance) работает хорошо: для стандартизации выбираются три технологических стека (простой, промежуточный и сложный) и предоставляется возможность отдельным требованиям сервиса управлять требованиями стека. Это дает командам свободу выбора подходящего технологического стека и одновременно дает компании некоторые преимущества стандартов.
Большой объем усилий, который тратится на предположения, даже если они через полгода оказываются ошибочными, приводит к сильной привязанности к ним. Невозвратные затраты1 описывают решения, принятые под влиянием эмоциональной вовлеченности. Проще говоря, чем больше кто-то тратит на что-то времени или усилий, тем тяжелее становится от них отказаться. В случае программного обеспечения это проявляется в форме иррациональной привязанности к артефактам — чем больше времени и усилий вы тратите на планирование или на документ, тем вероятнее вы будете защищать то, что содержится в составленном плане или документе, даже перед лицом доказательств того, что они неточные или устаревшие.
Не становитесь иррационально привязанными к сделанным вами артефактам.
Организуйте команды вокруг бизнес-возможностей, а не функциональных обязанностей.
КОМАНДЫ AMAZON «НА ДВЕ ПИЦЦЫ» Компания Amazon стала знаменита благодаря своему подходу к командам продукта, который они назвали команды на две пиццы. Их подход состоит в том, что ни одна команда не должна быть больше команды, которой можно скормить две крупные пиццы. Мотивация такого разделения в большей степени обусловлена общением, а не размером команды, потому что чем больше команда, тем с большим числом людей должен общаться каждый участник. Каждая команда является кросс-функциональной, и они также придерживаются принципа «ты это построил, ты на этом работаешь», то есть каждая команда полностью владеет сервисом, включая его практическую реализацию.
Организации могут поддерживать экспериментирование различными путями: 1. Заимствование чужих идей; 2. Поощрение явных улучшений; 3. Пробные и стабилизирующие решения; 4. Время для создания инновации 5. Следование комплексной разработке; 6. Связь инженеров с конечными пользователями