СПб.: Питер, 2019. — 272 с. — ISBN 978-5-4461-0995-1.
Пора по-новому взглянуть на постулаты, остававшиеся неизменными на
протяжении многих лет. Динамично меняющийся мир диктует свои
правила, в том числе и в компьютерной архитектуре. Происходящие
изменения требуют новых подходов, заставляют жесткие системы
становиться гибкими и подстраиваться под новые условия. Возможно ли
долгосрочное планирование, если всё непрерывно меняется? Как
предотвратить постепенное ухудшение архитектурного решения с
течением времени? Здесь вы найдете ответы и рекомендации, которые
позволят защитить самые важные характеристики проекта в условиях
непрерывных изменений.
"Эта книга знаменует собой важную веху, обозначающую нынешний
уровень понимания проблемы. По мере того, как люди начинают
осознавать роль ПО в XXI веке, информация о том, как реагировать на
изменения, сохраняя достигнутое, становится важнейшим навыком в
области создания программного обеспечения." - Мартин Фаулер
Предисловие
Долгое время разработчики программного обеспечения придерживались мнения, что архитектуру программного обеспечения следует разрабатывать до написания первой строки кода. Под влиянием строительной отрасли считалось, что признаком успешной архитектуры программного обеспечения было то, что в ней не надо ничего менять в процессе разработки, это часто было связано с высокими затратами на переделку архитектуры.
В дальнейшем с появлением методов гибкого программного обеспечения такое представление об архитектуре изменилось. Метод заранее спланированной архитектуры основывался на том, что установленные требования не должны были меняться до написания кода, что приводило к поэтапному (или каскадному) методу проектирования, в котором за установленными требованиями следовала разработка архитектуры, а за ней, в свою очередь, следовала разработка программного обеспечения. Однако динамично меняющийся мир поставил под сомнение саму идею неизменности требований, так как изменения требований оказались просто необходимы для ведения бизнеса в современном мире и обеспечивали планирование проекта, позволяющее вносить контролируемые изменения.
В этом новом гибком мире многие люди стали задаваться вопросом о роли архитектуры. И конечно же, заранее планируемая архитектура не могла приспособиться к изменчивости современного мира. При создании архитектуры используется другой метод, который гибким образом вносит необходимые изменения. При таком подходе разработка архитектуры выполняется в тесной связи с созданием программного обеспечения, так что архитектура может не только реагировать на изменение требований, но также принимать во внимание обратную связь от программирования. Мы обратимся к такой архитектуре с эволюционным развитием, чтобы показать, что даже в случае непредсказуемых изменений эта архитектура все еще может продолжать двигаться в правильном направлении.
Работая в компании ThoughtWorks, мы глубоко окунулись в это архитектурное мировоззрение. Ребекка вела многие из наших наиболее важных проектов в 2000-х и постепенно обеспечивала лидирующее положение, будучи руководителем технического отдела. Нил играл роль внимательного наблюдателя наших работ, синтезируя и передавая полученный нами опыт. Патрик совмещал свою работу над проектом с обеспечением нашего лидирующего положения в области техники. Мы всегда чувствовали жизненную важность создаваемой нами архитектуры и не могли довериться случаю. Совершая ошибки, мы получали бесценный опыт и начинали лучше понимать, как строить основу кода, которая могла бы эффективно реагировать на многие изменения своей цели.
В основе создания архитектуры с эволюционным развитием лежат небольшие изменения, которые с помощью обратной связи позволяют каждому узнать, как развивается система. Появление системы непрерывной поставки стало решающим фактором практической реализации архитектуры с эволюционным развитием. Авторское трио Нила, Ребекки и Патрика использует идею функций пригодности для управления состоянием архитектуры. Они изучают различные стили эволюционируемости архитектуры и делают акцент на проблемах, связанных с данными длительного хранения, — обычно этим пренебрегают. В большинстве пояснений, приведенных в этой книге, используется закон Конвея.
Несмотря на то что мы еще должны многое узнать о разработке архитектуры программного обеспечения эволюционирующего типа, эта книга знаменует собой важную веху, обозначающую текущее состояние понимания указанной проблемы. По мере того как все больше людей начинают осознавать роль систем программного обеспечения в XXI веке, знание того, как лучше всего реагировать на изменения, сохраняя достигнутое, будет важнейшим навыком в области создания программного обеспечения.
— Мартин Фаулер
martinfowler.com
Сентябрь 2017 г. Оглавление
Предисловие
Введение
Типографские соглашения
От научного редактора перевода
Как связаться с нами
Дополнительная информация
От издательства
Благодарности
Архитектура программного обеспечения
Архитектура с эволюционным развитием
Как можно осуществлять долгосрочное планирование,
если все постоянно меняется?
Как можно защитить созданную архитектуру
от постепенной деградации?
Инкрементные изменения
Управляемое изменение
Многочисленные области архитектуры
Закон Конвея
Почему эволюционное развитие?
Краткие выводы
Функции пригодности
Что собой представляет функция пригодности?
Категории
Атомарная и комплексная функции
Триггерные и непрерывные функции
Статические и динамические функции
Автоматизированная и ручная функции
Временная функция
Функция с преднамеренным развитием
Предметно-ориентированная функция
Ранняя идентификация функций пригодности
Пересмотр функций пригодности
Проектирование инкрементных изменений
Строительные блоки
Тестопригодность
Конвейеры развертывания
Комбинирование категорий функций пригодности
Практический пример: реструктуризация архитектуры
при ее развертывании 60 раз в день
Конфликтующие цели
Практический пример: добавление функций пригодности
в сервис выставления счетов PenultimateWidgets
Разработка, основанная на гипотезах и на данных
Практический пример: что портировать?
Архитектурная связанность
Модульность
Квант и гранулярность архитектуры
Эволюция архитектурных стилей
Большой комок грязи
Монолитная архитектура
Событийно-ориентированная архитектура
Сервис-ориентированные архитектуры
Бессерверная архитектура
Контроль размера кванта
Практический пример: предотвращение циклов компонентов
Эволюционирующие данные
Эволюционное проектирование баз данных
Эволюционные схемы
Интеграция базы данных общего использования
Ненадлежащая связанность данных
Двухфазная фиксация транзакций
Возраст и качество данных
Практический пример: эволюционирование методов
маршрутизации в PenultimateWidgets
Построение архитектуры с эволюционным развитием
Техники
Определить области, затрагиваемые эволюционным развитием
Определить для каждой области функцию(-и) пригодности
Использовать конвейер развертывания для автоматизации функций пригодности
Проекты с нуля
Настройка существующих архитектур
Надлежащие связанность и сцепление
Практики проектирования
Функции пригодности
Применение коммерческой продукции
Миграция архитектур
Шаги миграции
Эволюция модульных взаимодействий
Инструкции для построения эволюционирующей архитектуры
Удаление ненужной изменчивости
Сделайте решения обратимыми
Предпочтение следует отдавать эволюционированию, а не предсказуемости
Построение уровня защиты от повреждений
Практический пример: шаблоны сервисов
Построение жертвенной архитектуры
Уменьшить внешние изменения
Обновление библиотек и фреймворков
Отдавайте предпочтение непрерывной поставке, а не снимкам состояния системы
Версии внутренних сервисов
Практический пример: эволюционирование рейтингов PenultimateWidgets
Архитектура с эволюционным развитием: ловушки и антипаттерны
Техническая архитектура
Антипаттерн: Vendor King
Ловушка: дырявая абстракция
Антипаттерн: ловушка на последних 10%
Антипаттерн: неправильное повторное использование кода
Практический пример: принцип повторного использования в PenultimateWidgets
Ловушка: разработки ради резюме
Инкрементные изменения
Антипаттерн: ненадлежащее управление
Практический пример: модель управления
«золотой середины» в PenultimateWidgets
Ловушка: недостаточная скорость для релиза
Проблемы бизнеса
Ловушка: адаптация продукта
Антипаттерн: составление отчетов
Ловушка: горизонты планирования
Внедрение эволюционной архитектуры
Организационные факторы
Кросс-функциональные команды
Организованные бизнес-возможности
Продукт важнее, чем проект
Работа с внешним изменением
Связи между участниками команды
Характеристики связей между командами
Культура
Культура эксперимента
Операционный денежный поток (OCF) и бюджетирование
Разработка функций пригодности для предприятия
Оглавление
Практический пример: PenultimateWidgets как платформа
С чего мы начнем?
Низко висящие фрукты
Максимальная ценность
Тестирование
Инфраструктура
Практический пример: архитектура предприятия в компании PenultimateWidgets
Будущее состояние?
Функции пригодности, использующие
искусственный интеллект
Генеративное тестирование
Зачем это (или почему бы и нет)?
Зачем та или иная компания решает строить
эволюционирующую архитектуру?
Практический пример: избирательный масштаб в PenultimateWidgets
По какой причине компания делает выбор не строить эволюционирующую архитектуру?
Убеждая других
Практический пример: консультация по системе дзюдо
Пример из бизнеса
«Будущее уже наступило…»
Двигаться быстро и без аварий
Меньше риска
Новые возможности
Построение архитектуры с эволюционным развитием
Об авторах
Выходные данные
Долгое время разработчики программного обеспечения придерживались мнения, что архитектуру программного обеспечения следует разрабатывать до написания первой строки кода. Под влиянием строительной отрасли считалось, что признаком успешной архитектуры программного обеспечения было то, что в ней не надо ничего менять в процессе разработки, это часто было связано с высокими затратами на переделку архитектуры.
В дальнейшем с появлением методов гибкого программного обеспечения такое представление об архитектуре изменилось. Метод заранее спланированной архитектуры основывался на том, что установленные требования не должны были меняться до написания кода, что приводило к поэтапному (или каскадному) методу проектирования, в котором за установленными требованиями следовала разработка архитектуры, а за ней, в свою очередь, следовала разработка программного обеспечения. Однако динамично меняющийся мир поставил под сомнение саму идею неизменности требований, так как изменения требований оказались просто необходимы для ведения бизнеса в современном мире и обеспечивали планирование проекта, позволяющее вносить контролируемые изменения.
В этом новом гибком мире многие люди стали задаваться вопросом о роли архитектуры. И конечно же, заранее планируемая архитектура не могла приспособиться к изменчивости современного мира. При создании архитектуры используется другой метод, который гибким образом вносит необходимые изменения. При таком подходе разработка архитектуры выполняется в тесной связи с созданием программного обеспечения, так что архитектура может не только реагировать на изменение требований, но также принимать во внимание обратную связь от программирования. Мы обратимся к такой архитектуре с эволюционным развитием, чтобы показать, что даже в случае непредсказуемых изменений эта архитектура все еще может продолжать двигаться в правильном направлении.
Работая в компании ThoughtWorks, мы глубоко окунулись в это архитектурное мировоззрение. Ребекка вела многие из наших наиболее важных проектов в 2000-х и постепенно обеспечивала лидирующее положение, будучи руководителем технического отдела. Нил играл роль внимательного наблюдателя наших работ, синтезируя и передавая полученный нами опыт. Патрик совмещал свою работу над проектом с обеспечением нашего лидирующего положения в области техники. Мы всегда чувствовали жизненную важность создаваемой нами архитектуры и не могли довериться случаю. Совершая ошибки, мы получали бесценный опыт и начинали лучше понимать, как строить основу кода, которая могла бы эффективно реагировать на многие изменения своей цели.
В основе создания архитектуры с эволюционным развитием лежат небольшие изменения, которые с помощью обратной связи позволяют каждому узнать, как развивается система. Появление системы непрерывной поставки стало решающим фактором практической реализации архитектуры с эволюционным развитием. Авторское трио Нила, Ребекки и Патрика использует идею функций пригодности для управления состоянием архитектуры. Они изучают различные стили эволюционируемости архитектуры и делают акцент на проблемах, связанных с данными длительного хранения, — обычно этим пренебрегают. В большинстве пояснений, приведенных в этой книге, используется закон Конвея.
Несмотря на то что мы еще должны многое узнать о разработке архитектуры программного обеспечения эволюционирующего типа, эта книга знаменует собой важную веху, обозначающую текущее состояние понимания указанной проблемы. По мере того как все больше людей начинают осознавать роль систем программного обеспечения в XXI веке, знание того, как лучше всего реагировать на изменения, сохраняя достигнутое, будет важнейшим навыком в области создания программного обеспечения.
— Мартин Фаулер
martinfowler.com
Сентябрь 2017 г. Оглавление
Предисловие
Введение
Типографские соглашения
От научного редактора перевода
Как связаться с нами
Дополнительная информация
От издательства
Благодарности
Архитектура программного обеспечения
Архитектура с эволюционным развитием
Как можно осуществлять долгосрочное планирование,
если все постоянно меняется?
Как можно защитить созданную архитектуру
от постепенной деградации?
Инкрементные изменения
Управляемое изменение
Многочисленные области архитектуры
Закон Конвея
Почему эволюционное развитие?
Краткие выводы
Функции пригодности
Что собой представляет функция пригодности?
Категории
Атомарная и комплексная функции
Триггерные и непрерывные функции
Статические и динамические функции
Автоматизированная и ручная функции
Временная функция
Функция с преднамеренным развитием
Предметно-ориентированная функция
Ранняя идентификация функций пригодности
Пересмотр функций пригодности
Проектирование инкрементных изменений
Строительные блоки
Тестопригодность
Конвейеры развертывания
Комбинирование категорий функций пригодности
Практический пример: реструктуризация архитектуры
при ее развертывании 60 раз в день
Конфликтующие цели
Практический пример: добавление функций пригодности
в сервис выставления счетов PenultimateWidgets
Разработка, основанная на гипотезах и на данных
Практический пример: что портировать?
Архитектурная связанность
Модульность
Квант и гранулярность архитектуры
Эволюция архитектурных стилей
Большой комок грязи
Монолитная архитектура
Событийно-ориентированная архитектура
Сервис-ориентированные архитектуры
Бессерверная архитектура
Контроль размера кванта
Практический пример: предотвращение циклов компонентов
Эволюционирующие данные
Эволюционное проектирование баз данных
Эволюционные схемы
Интеграция базы данных общего использования
Ненадлежащая связанность данных
Двухфазная фиксация транзакций
Возраст и качество данных
Практический пример: эволюционирование методов
маршрутизации в PenultimateWidgets
Построение архитектуры с эволюционным развитием
Техники
Определить области, затрагиваемые эволюционным развитием
Определить для каждой области функцию(-и) пригодности
Использовать конвейер развертывания для автоматизации функций пригодности
Проекты с нуля
Настройка существующих архитектур
Надлежащие связанность и сцепление
Практики проектирования
Функции пригодности
Применение коммерческой продукции
Миграция архитектур
Шаги миграции
Эволюция модульных взаимодействий
Инструкции для построения эволюционирующей архитектуры
Удаление ненужной изменчивости
Сделайте решения обратимыми
Предпочтение следует отдавать эволюционированию, а не предсказуемости
Построение уровня защиты от повреждений
Практический пример: шаблоны сервисов
Построение жертвенной архитектуры
Уменьшить внешние изменения
Обновление библиотек и фреймворков
Отдавайте предпочтение непрерывной поставке, а не снимкам состояния системы
Версии внутренних сервисов
Практический пример: эволюционирование рейтингов PenultimateWidgets
Архитектура с эволюционным развитием: ловушки и антипаттерны
Техническая архитектура
Антипаттерн: Vendor King
Ловушка: дырявая абстракция
Антипаттерн: ловушка на последних 10%
Антипаттерн: неправильное повторное использование кода
Практический пример: принцип повторного использования в PenultimateWidgets
Ловушка: разработки ради резюме
Инкрементные изменения
Антипаттерн: ненадлежащее управление
Практический пример: модель управления
«золотой середины» в PenultimateWidgets
Ловушка: недостаточная скорость для релиза
Проблемы бизнеса
Ловушка: адаптация продукта
Антипаттерн: составление отчетов
Ловушка: горизонты планирования
Внедрение эволюционной архитектуры
Организационные факторы
Кросс-функциональные команды
Организованные бизнес-возможности
Продукт важнее, чем проект
Работа с внешним изменением
Связи между участниками команды
Характеристики связей между командами
Культура
Культура эксперимента
Операционный денежный поток (OCF) и бюджетирование
Разработка функций пригодности для предприятия
Оглавление
Практический пример: PenultimateWidgets как платформа
С чего мы начнем?
Низко висящие фрукты
Максимальная ценность
Тестирование
Инфраструктура
Практический пример: архитектура предприятия в компании PenultimateWidgets
Будущее состояние?
Функции пригодности, использующие
искусственный интеллект
Генеративное тестирование
Зачем это (или почему бы и нет)?
Зачем та или иная компания решает строить
эволюционирующую архитектуру?
Практический пример: избирательный масштаб в PenultimateWidgets
По какой причине компания делает выбор не строить эволюционирующую архитектуру?
Убеждая других
Практический пример: консультация по системе дзюдо
Пример из бизнеса
«Будущее уже наступило…»
Двигаться быстро и без аварий
Меньше риска
Новые возможности
Построение архитектуры с эволюционным развитием
Об авторах
Выходные данные