Привет, Хаброжители!Новые инструменты, фреймворки методики и парадигмы вновь и вновь меняют экосистему
разработки программного обеспечения. Непрерывный прогресс основных практик разработки
на протяжении последних пяти лет заставил искать новые пути и подходы к архитектуре, чтобы
соответствовать постоянно меняющимся требованиям пользователей. В обновленном издании
авторы Нил Форд, Ребекка Парсонс, Патрик Куа и Прамод Садаладж приводят реальные примеры, соответствующие потребностям современной разработки ПО.
«Эта книга знаменует собой важную веху, обозначающую нынешний уровень понимания проблемы. По мере того как люди начинают осознавать роль ПО в XXI веке, информация о том, как реагировать на изменения, сохраняя достигнутое, становится важнейшим навыком в области создания программного обеспечения». — Мартин Фаулер.
Структура издания
Мы изменили структуру по сравнению с первым изданием, четко разграничив две основные темы: инженерные практики создания эволюционных программных систем и структурные подходы, которые облегчают этот процесс.
В первой части мы рассматриваем механизмы и практики разработки, подходящие для реализации эволюционной архитектуры, в том числе методы, инструменты, категории и все, что необходимо читателям для понимания этой темы.
Программная архитектура также включает проектирование структур, и существуют решения, которые облегчают их эволюцию (и управление ими). Мы расскажем об этом в части II, которая, кроме того, включает обзор стилей архитектуры, а также принципов проектирования, основанных на связанности, повторном использовании и других важных структурных соображениях.
В программной архитектуре практически не существует изолированных элементов; многие принципы и практики эволюционной архитектуры предполагают комплексное взаимодействие составляющих процесса разработки, о чем мы расскажем в части III.
В первой части мы рассматриваем механизмы и практики разработки, подходящие для реализации эволюционной архитектуры, в том числе методы, инструменты, категории и все, что необходимо читателям для понимания этой темы.
Программная архитектура также включает проектирование структур, и существуют решения, которые облегчают их эволюцию (и управление ими). Мы расскажем об этом в части II, которая, кроме того, включает обзор стилей архитектуры, а также принципов проектирования, основанных на связанности, повторном использовании и других важных структурных соображениях.
В программной архитектуре практически не существует изолированных элементов; многие принципы и практики эволюционной архитектуры предполагают комплексное взаимодействие составляющих процесса разработки, о чем мы расскажем в части III.
Подводные камни и антипаттерны эволюционной архитектуры
Мы не раз возвращались к важности выбора подходящего уровня связанности в архитектурах. Однако мы живем в реальном мире и встречаем связанность, которая вредит эволюционности проектов.
В программных проектах встречается два вида плохих практик — подводные камни и антипаттерны. Многие разработчики используют слово «антипаттерн» как жаргонный синоним плохого, но его значение несколько тоньше. Во-первых, антипаттерн — это практика, которая вначале выглядела подходящей, но оказалась ошибочной. Во-вторых, для большинства антипаттернов существуют лучшие альтернативы. Многие антипаттерны становятся очевидны только задним числом, поэтому их трудно избежать. Подводные камни выглядят как хорошая идея, но то, что это плохой путь, становится понятно сразу же. В этой главе мы рассмотрим и подводные камни, и антипаттерны.
Техническая архитектура
В этом разделе мы разберем распространенные в отрасли практики, которые вредят способности команд развивать архитектуру.
Антипаттерн: ловушка последних 10 % и Low Code/No Code
В свое время Нил был техническим директором консалтинговой фирмы, которая создавала проекты для клиентов, используя инструменты четвертого поколения (4GL), в том числе Microsoft Access. Он добился прекращения использования Access и всех таких инструментов после того, как заметил, что каждый проект Access начинался успешно, но заканчивался неудачей, и захотел понять почему.
Они с коллегой выяснили, что в Access и других популярных в то время инструментах 4GL 80 % потребностей клиента удовлетворялись легко и быстро. Эти среды моделировались как инструменты быстрой разработки приложений, с поддержкой перетаскивания (drag and drop) в пользовательском интерфейсе и другими полезными штуками. Однако следующие 10 % потребностей клиента удовлетворить было хоть и можно, но крайне сложно, потому что требуемая функциональность не была встроена в инструмент, фреймворк или язык. Поэтому умные разработчики придумали способ взломать инструменты: добавлением скрипта для выполнения там, где ожидалось статическое действие, образованием цепочек методов и так далее. Это дало возможность удовлетворять от 80 до 90 % потребностей. Инструмент все равно не мог решить проблему полностью — и это стало называться ловушкой последних 10 % (Last 10 % Trap), из-за которой проекты терпели неудачу. 4GL-инструменты позволяли быстро создавать простые вещи, но они не масштабировались, чтобы соответствовать требованиям реального мира. Разработчики вернулись к языкам общего назначения.
Ловушка последних 10 % периодически проявляется в инструментах, призванных устранить сложность разработки и (якобы) обеспечить полнофункциональную разработку с предсказуемыми результатами. В современной разработке она актуальна для сред low-code/no-code, от full-stack-разработки до специализированных инструментов, таких как оркестраторы.
Хотя в средах low-code нет ничего плохого, их значение почти повсеместно преувеличивают, считая панацеей для разработки благодаря высокой скорости доставки. Их можно применять для решения специализированных задач, но необходимо осознавать существующие ограничения и уметь определять, какое влияние эти ограничения окажут на экосистему.
Обычно, экспериментируя с новым инструментом или фреймворком, разработчики создают простой проект Hello, World. В средах low-code простые вещи чрезвычайно просты, и, наоборот, необходимо знать, что в них сделать невозможно. Таким образом, на этапе тестирования инструмента вместо создания простых проектов постарайтесь найти пределы его функциональности, чтобы предусмотреть альтернативы для случаев, с которыми он не справится.
Практический пример: повторное использование в PenultimateWidgets
Административная функциональность PenultimateWidgets предусматривает ввод данных в специализированную сетку. Поскольку это представление требуется в нескольких местах, PenultimateWidgets решила создать многократно используемый компонент, включающий пользовательский интерфейс, валидацию и другие полезные модели поведения по умолчанию. Используя этот компонент, можно легко создавать новые, подробные интерфейсы администрирования.
Однако ни одно архитектурное решение не обходится без компромиссов. Со временем команда разработчиков компонента превратилась в силос внутри организации, поглотивший нескольких лучших программистов PenultimateWidgets. Команды, использующие компонент, должны запрашивать новые функции у команды разработчиков компонента, которая оказалась завалена исправлениями ошибок и запросами функций. Хуже того, базовый код не соответствует современным веб-стандартам, что затрудняет или делает невозможным внедрение новых функций.
Хотя архитекторы PenultimateWidgets реализовали повторное использование, в конечном итоге это привело к возникновению узкого места. Одно из преимуществ повторного использования в том, что оно позволяет быстро создавать новые функции. Однако если разработчики компонентов не будут успевать за темпами инноваций в условиях динамического равновесия, повторное использование компонентов технической архитектуры обречено стать антипаттерном.
Мы не предлагаем отказаться от создания многократно используемых активов — скорее необходимо постоянно проверять, что они по-прежнему полезны. В случае с PenultimateWidgets, как только архитекторы поняли, что компонент является узким местом, они разорвали точку сцепления. Они разрешили всем, кому это требовалось, самостоятельно добавлять новые функции в код компонента (при условии, что команда разработчиков приложения поддерживала предлагаемые изменения), и перевели все команды, желавшие отказаться от прежнего подхода, на новую модель.
Из опыта PenultimateWidgets можно сделать два вывода. Во-первых, если точки сцепления препятствуют эволюции или ухудшают важные характеристики архитектуры, необходимо разорвать связанность путем ветвления или дублирования.
В PenultimateWidgets связанность разорвали, позволив командам самим отвечать за общий код. Хотя это и увеличило их нагрузку, но одновременно и повысило производительность. В других случаях, как вариант, можно абстрагировать часть общего кода от более крупного фрагмента, чтобы добиться выборочной связанности и частичного разделения.
Во-вторых, необходимо постоянно оценивать пригодность характеристик архитектуры, чтобы убедиться, что они по-прежнему эффективны и не превратились в антипаттерны.
Слишком часто случается так, что решение, которое было правильным на момент своего принятия, со временем становится не лучшим выбором из-за изменившихся условий, таких как динамическое равновесие. Например, архитекторы разрабатывают систему как настольное приложение, но развитие отрасли вынуждает их создавать веб-версию, поскольку привычки пользователей меняются. Исходное решение не было ошибочным, но экосистема неожиданно изменилась.
Антипаттерн: Король-поставщик
Некоторые крупные компании покупают ПО для планирования ресурсов предприятия (ERP, enterprise resource planning), чтобы оптимизировать основные бизнес-задачи, такие как бухгалтерский учет, управление запасами и другие. Это работает, если компании готовы изменить свои бизнес-процессы и решения, чтобы настроить инструмент; кроме того, его можно использовать стратегически, если архитекторы представляют себе не только его преимущества, но и сопутствующие ограничения.
Однако часто организации возлагают на такое ПО слишком много надежд, что приводит к антипаттерну Король-поставщик (Vendor King), когда архитектура строится полностью вокруг продукта одного поставщика, что делает организацию патологически зависимой от этого инструмента. Приобретая ПО у поставщика, компании планируют дополнить пакет подключаемыми модулями, чтобы основные функции соответствовали потребностям бизнеса. Однако в большинстве случаев ERP-инструменты невозможно настроить так, чтобы полностью реализовать необходимое, и разработчики оказываются в ловушке ограничений инструмента, а также того факта, что он стал центром архитектурной вселенной. Другими словами, поставщик стал королем архитектуры организации, диктующим будущие решения.
Чтобы защититься от этого антипаттерна, рассматривайте все ПО как точку интеграции, даже если изначально оно предназначено для широкого круга задач. Это поможет заменить неэффективное поведение другими точками интеграции и свергнуть короля.
Помещая внешний инструмент или фреймворк в основу архитектуры, разработчики существенно ограничивают ее способность к эволюции как с технической точки зрения, так и с точки зрения бизнес-процессов. В части технологий возможности разработчиков будут ограничены решением поставщика в отношении персистентности, поддерживаемой инфраструктуры и множеством других ограничений. В части бизнеса большие инкапсулирующие инструменты подвержены рискам, описанным в разделе «Антипаттерн: ловушка последних 10 % и Low Code/No Code» на с. 212. Инструменты оказываются просто не способны поддерживать оптимальный рабочий процесс; это побочный эффект ловушки последних 10 %. Большинство компаний в итоге уступают фреймворкам, изменяя свои процессы, а не пытаясь настроить инструмент. Чем больше компаний так делают, тем меньше между ними разница, что вполне нормально, пока эта разница не добавляет конкурентного преимущества. Компании часто выбирают альтернативный вариант, описанный в разделе «Подводный камень: персонализация продукта» на с. 224 и являющийся еще одной ловушкой.
Зачастую при работе с ERP-пакетами все заканчивается словами: «Давайте закончим и скажем, что все получилось». Поскольку эти системы требуют огромных затрат времени и денег, компании неохотно признают, что затея провалилась. Ни один технический директор не признает, что потратил впустую миллионы долларов, а поставщик не согласится, что за несколько лет внедрить инструмент так и не получилось. Поэтому обе стороны соглашаются остановиться и объявить об успехе, хотя большая часть обещанного функционала осталась нереализованной.
Чтобы не стать жертвой антипаттерна Король-поставщик, рассматривайте продукты поставщиков как еще одну точку интеграции. Изолировать изменения в инструментах поставщиков, чтобы они не влияли на архитектуру, можно с помощью защитного слоя между точками интеграции.
Подводный камень: дырявые абстракции
Все нетривиальные абстракции в какой-то степени дырявые.
— Джоэл Спольски (Joel Spolsky)
Современное ПО состоит из абстракций: операционных систем, фреймворков, зависимостей и множества других частей. Мы создаем абстракции, чтобы нам не приходилось постоянно работать на самых низких уровнях. Если бы разработчики должны были переводить двоичный код с жестких дисков в текст, они бы никогда ничего не сделали! Развитие современного ПО во многом обусловлено тем, что мы смогли создавать эффективные абстракции.
Но за абстракции приходится платить, потому что ни одна абстракция не совершенна, иначе это была бы не абстракция, а реальная вещь. Как сказал Джоэл Спольски, все нетривиальные абстракции дырявы. Это проблема для разработчиков, потому что мы привыкли верить, что абстракции всегда точны, но они часто и неожиданно ломаются.
Возросшая сложность технологического стека усугубила проблему отвлечения абстракций. Рассмотрим типичный технологический стек примерно 2005 года, показанный на рис. 8.1.
В стеке, изображенном на рис. 8.1, названия поставщиков на коробках меняются в зависимости от местных условий. Со временем, по мере роста специализации ПО, технологический стек усложняется, как показано на рис. 8.2.
Как видно на рис. 8.2, все части экосистемы расширились и приобрели дополнительную сложность. По мере усложнения проблем усложняются и их решения.
Первобытная, то есть низкоуровневая, абстракция, нарушение которой приводит к возникновению хаоса, — один из побочных эффектов усложнения технологического стека. Что, если сбой, например, неожиданный побочный эффект от простого, на первый взгляд, обращения к базе данных, возникнет в одной из низкоуровневых абстракций? Поскольку уровней много, сбой будет распространяться до вершины стека, проявляясь в пользовательском интерфейсе в виде сообщения об ошибке на глубоком уровне. По мере усложнения технологического стека становится тяжелее проводить отладку и ретроспективный анализ.
Проанализируйте абстракцию хотя бы на один уровень ниже того, на котором вы обычно работаете.
— Коллективное мнение мудрецов разработки
Хотя совет проанализировать нижележащий слой хорош, следовать ему становится все труднее, поскольку повышается специализация программ и, следовательно, увеличивается их сложность.
Увеличение сложности технологического стека — пример проблемы динамического равновесия. Меняется не только экосистема, но и ее компоненты, которые со временем усложняются и теснее связываются между собой. Наш механизм защиты эволюционных изменений — фитнес-функции — способен защитить хрупкие точки сцепления архитектуры. Чтобы избежать нежелательных утечек абстракции, архитекторы задают инварианты в ключевых точках интеграции в виде фитнес-функций, которые запускаются в рамках пайплайна развертывания.
Подводный камень: разработка ради строчки в резюме
Зачастую архитекторы увлекаются последними возможностями разработки и стремятся использовать все новейшие игрушки. Однако, чтобы создавать эффективную архитектуру, необходимо внимательно изучить предметную область и выбрать наиболее подходящий дизайн, реализующий максимум возможностей при минимуме разрушительных ограничений. Если, конечно, целью архитектора не является разработка ради строчки в резюме — использовать все возможные фреймворки и библиотеки только для того, чтобы похвастаться своими знаниями.
Всегда определяйте предметную область до выбора архитектуры, а не наоборот.
Инкрементные изменения
Вносить изменения инкрементно при разработке зачастую довольно сложно. Десятилетиями программы писались с учетом в первую очередь таких факторов, как снижение затрат, совместное использование ресурсов и других внешних ограничений, а гибкость отходила на второй план. Вследствие этого во многих компаниях отсутствуют структурные элементы эволюционных архитектур.
Как отмечается в книге «Continuous Delivery», многие современные практики разработки поддерживают эволюционную архитектуру.
Антипаттерн: ненадлежащее управление
Программная архитектура не существует в вакууме — она является отражением внешних условий. Еще 10 лет назад операционные системы стоили дорого. Такими же коммерческими и дорогими были серверы баз данных, серверы приложений и вся инфраструктура для размещения приложений. Поэтому создаваемые архитектуры были нацелены на максимальное совместное использование ресурсов. Это была эпоха расцвета таких паттернов, как СОА. В этой среде развивалась модель управления, поощряющая общие ресурсы как метод экономии затрат.
Она стала основой коммерческой мотивации для многих инструментов, таких как серверы приложений. Однако размещать множество ресурсов на машинах нежелательно из-за возникновения непреднамеренной связанности. Совместно используемые ресурсы могут быть эффективно изолированы друг от друга, но в конечном счете борьба за ресурсы дает о себе знать.
За последнее десятилетие динамическое равновесие экосистемы разработки изменилось. Теперь можно создавать архитектуры, в которых компоненты имеют высокую степень изоляции (например, микросервисы), что позволяет избежать непреднамеренной связанности в общих средах. Тем не менее многие компании по-прежнему придерживаются старой модели управления. Однако модель с упором на совместно используемые ресурсы и однородные среды становится неэффективной в современных условиях, в частности с развитием DevOps.
Теперь все компании — разработчики.
— Журнал Forbes, 30 ноября 2011 г.
Смысл этой известной фразы Forbes в том, что если приложение авиакомпании, созданное для iPad, работает плохо, то это скажется на ее итоговых показателях. Любая передовая компания, и все чаще любая компания, которая хочет оставаться конкурентоспособной, должна обладать достаточными компетециями в области разработки. И частью этой компетенции является управление активами разработки, такими как среда.
Когда появляется возможность создавать такие ресурсы, как виртуальные машины и контейнеры, без каких-либо затрат (денег или времени), модель управления с упором на одно решение становится ненадлежащей (негодной). Создание множественных сред микросервисов — более эффективный подход. Одна из особенностей микросервисных архитектур — принятие полиглотных сред, когда каждая команда может выбрать подходящий стек технологий для реализации своего сервиса, а не вынуждена использовать корпоративный стандарт. Архитекторов систем предприятий, использующих традиционный подход, коробят такие слова, поскольку они абсолютно противоречат их принципам. Однако цель большинства проектов микросервисов не в том, чтобы беспорядочно перебирать технологии, а в том, чтобы подобрать именно ту, которая подходит для решения проблемы.
В современных средах использовать единый технологический стек нецелесообразно. Это приводит к непреднамеренному усложнению, когда управленческие решения только добавляют сложности и не способствуют решению задачи. Например, стандартная практика в крупных компаниях — использование реляционной базы данных одного поставщика, и на то есть очевидные причины: согласованность проектов, легкая сменяемость сотрудников и др. Однако у такого подхода есть побочный эффект: большинство проектов страдают от избыточного проектирования. В монолитных архитектурах управленческие решения затрагивают все компоненты. Таким образом, архитектор должен выбрать базу данных, удовлетворяющую самым сложным из существующих требований каждого проекта, в котором она будет использована. К сожалению, во многих проектах такая сложность не нужна. В небольших проектах простые требования к персистентности, однако для обеспечения согласованности в них приходится использовать всю сложность промышленного сервера баз данных.
В микросервисах каждая команда может выбрать подходящий уровень сложности для своего сервиса, поскольку ни один из них не связан ни с технической архитектурой, ни с архитектурой данных. В конечном счете сложность стека сервисов приводится в соответствие с техническими требованиями. Такое разделение, как правило, наиболее эффективно, когда команда полностью владеет своим сервисом, отвечая в том числе за эксплуатационные параметры.
ПРИНУДИТЕЛЬНОЕ РАЗДЕЛЕНИЕ
Одна из особенностей архитектуры микросервисов — экстремальное техническое разделение (decoupling), позволяющее заменять сервисы без побочных эффектов. Однако при использовании одной и той же кодовой базы или даже платформы отсутствие связанности требует от разработчиков определенной дисциплины (поскольку соблазн повторно использовать существующий код очень велик) и мер предосторожности, чтобы не создать случайную связанность. Создание сервисов в разных технологических стеках — один из способов разделения технической архитектуры. Многие компании избегают этого подхода, поскольку опасаются, что это затруднит перемещение сотрудников между проектами. Однако Чад Фаулер (http://chadfowler.com/), бывший архитектор компании Wunderlist, придерживается противоположного мнения: он настаивает на использовании разных технологических стеков, чтобы избежать случайной связанности. Он считает, что случайная связанность — проблема посерьезнее, чем мобильность разработчиков.
Многие компании инкапсулируют отдельные функциональные возможности в платформу как услугу для внутреннего использования, скрывая выбор технологии (и, соответственно, возможности связанности) за хорошо определенными интерфейсами.
С практической точки зрения для крупных организаций хорошо работает модель управления «необходимо и достаточно»: стандартизируйте три технологических стека: простой, промежуточный и сложный — и позвольте выбирать какой-то из них на основе индивидуальных требований к разрабатываемому сервису. Это обеспечит разработчикам гибкость выбора подходящего технологического стека и в то же время сохранит для компании преимущества стандартизации.
Практический пример: «необходимое и достаточное» управление в PenultimateWidgets
В течение нескольких лет архитекторы PenultimateWidgets пытались стандартизировать всю разработку на Java и Oracle. Однако с повышением уровня детализации сервисов они поняли, что этот стек накладывает большую сложность на небольшие сервисы. Но архитекторы не готовы были полностью переходить на подход «каждому проекту свой технологический стек», поскольку им все еще была важна переносимость знаний и навыков между проектами. В итоге они выбрали «необходимое и достаточное» управление с тремя технологическими стеками:
Малый
Для очень простых проектов без жестких требований к масштабируемости или производительности они выбрали Ruby on Rails и MySQL.
Средний
Для средних проектов выбрали GoLang, а в качестве бэкенда Cassandra, MongoDB или MySQL в зависимости от требований к данным.
Крупный
Для крупных проектов остановились на Java и Oracle, поскольку они хорошо работают с различными архитектурными сложностями.
Подводный камень: недостаточная скорость выпуска релизов
Практика непрерывной доставки (http://continuousdelivery.com/) устраняет факторы, замедляющие выпуск релизов ПО, и считается аксиомой для создания успешной эволюционной архитектуры. Хотя экстремальная разновидность непрерывной доставки — непрерывное развертывание — для эволюционной архитектуры не требуется, возможность эволюции дизайна выпускаемого продукта сильно зависит от способности команд своевременно выпускать релизы.
Если инженерная культура компании основана на непрерывном развертывании, когда изменения попадают в продакшен только после пайплайна развертывания, разработчики привыкают к тому, что изменения должны быть постоянными. С другой стороны, если выпуск релизов в компании представляет собой формальный процесс, требующий большого количества специальных действий, шансы на создание эволюционной архитектуры уменьшаются.
Непрерывная доставка стремится получать результаты на основе данных и использовать метрики для оптимизации проектов. Разработчики должны уметь измерять параметры, чтобы понять, как сделать их лучше. Одна из ключевых метрик непрерывной доставки — время цикла (cycle time). Это метрика, связанная с временем производства (lead time): время от принятия идеи до ее воплощения в работающем продукте. Однако время производства включает в себя множество субъективных действий, таких как оценка, определение приоритетов и другие, что делает его непригодной в инженерии метрикой. Вместо этого в непрерывной доставке используется время цикла: время от начала до завершения единицы работы, которой в данном случае является разработка продукта. Отсчет времени цикла стартует, когда разработчик начинает работать над новой функцией, и заканчивается, когда эта функция запускается на продакшен. Цель времени цикла — измерить эффективность разработки; сокращение времени цикла — одна из ключевых целей непрерывной доставки.
Время цикла важно и для эволюционной архитектуры. В биологии генетические эксперименты обычно проводятся на плодовых мушках отчасти потому, что у них быстрый жизненный цикл — новые поколения появляются достаточно быстро, чтобы увидеть ощутимые результаты. То же справедливо и для эволюционной архитектуры — более быстрое время цикла означает, что архитектура может развиваться быстрее. Таким образом, время цикла проекта определяет, насколько быстро может развиваться архитектура. Другими словами, скорость эволюции пропорциональна времени цикла, что выражается следующей формулой:
где v — скорость изменений, а c — время цикла. Система не может развиваться быстрее, чем время цикла проекта. Другими словами, чем быстрее команды выпускают релизы, тем быстрее они развивают части своей системы.
Поэтому время цикла — критическая метрика эволюционной архитектуры: более быстрое время цикла подразумевает более быструю способность к эволюции. Фактически время цикла — идеальная атомарная фитнес-функция, основанная на процессе. Например, разработчики создают проект с автоматическим пайплайном развертывания, достигая времени цикла в три часа. Со временем оно постепенно увеличивается, поскольку в пайплайн добавляют все больше проверок и точек интеграции. Поскольку метрика времени выхода на рынок (time to market) важна в этом проекте, разработчики задают фитнес-функцию, которая будет подавать сигнал тревоги, если время цикла превысит четыре часа. Когда оно достигнет этого порога, можно либо перестроить работу пайплайна развертывания, либо оставить четырехчасовое значение как приемлемое. Фитнес-функции можно привязать к любому поведению, которое важно отслеживать в проектах, включая метрики проекта. Объединение важных параметров проекта в фитнес-функции позволяет разработчикам определять будущие точки принятия решений, также известные как последний ответственный момент.
В предыдущем примере разработчики теперь должны решить, что важнее: трехчасовое время цикла или набор тестов, которые у них есть. В большинстве проектов разработчики принимают это решение неявно, не замечая, как постепенно увеличивается время цикла, и таким образом не расставляя приоритеты между противоречащими друг другу целями. С помощью фитнес-функций можно установить пороговые значения для предполагаемых будущих точек принятия решений.
Для создания успешной эволюционной архитектуры чрезвычайно важна правильная организация проектирования, развертывания и выпуска релизов. В свою очередь, эволюционная архитектура позволяет создавать новые возможности для бизнеса с помощью разработки на основе гипотез (hypothesis-driven development).
Об авторах
Нил Форд — директор, архитектор ПО и идейный вдохновитель в ThoughtWorks, компании-разработчике программного обеспечения, объединяющей увлеченных, целеустремленных людей с нестандартным мышлением, что помогает создавать технологии для решения самых сложных задач, производящие революцию в ИТ-индустрии и стимулирующие позитивные перемены в обществе. До прихода в ThoughtWorks Нил был директором по технологиям в DSW Group, Ltd., компании национального уровня, специализирующейся на тренингах и развитии.
Нил имеет степень в области computer science Университета штата Джорджия (со специализацией на языках и компиляторах) и дополнительную степень в области математики (со специализацией на статистическом анализе). Он заслужил международное признание как эксперт в области разработки и доставки программного обеспечения, в частности на стыке agile-методологии и программной архитектуры. Нил является автором ряда статей в тематических журналах, девяти книг (и их число продолжает расти) и десятков видеопрезентаций, а также спикером сотен конференций разработчиков по всему миру. Его работы посвящены вопросам программной архитектуры, непрерывной доставки, функционального программирования и инноваций в сфере ПО, а кроме того, у него есть книга, ориентированная на бизнес, и видео на тему улучшения качества технических презентаций. Он является консультантом в сфере проектирования и создания крупномасштабных корпоративных приложений. Если вы хотите узнать больше о сферах интересов Нила, посетите его веб-сайт nealford.com.
Доктор Ребекка Парсонс — технический директор ThoughtWorks, имеющая многолетний опыт разработки приложений для различных отраслей и систем. Ее технические компетенции включают руководство созданием крупномасштабных распределенных объектных приложений, интеграцию разрозненных систем и работу с командами архитекторов. Помимо своей глубокой страсти к технологиям она активно продвигает разнообразие в технологической отрасли.
До прихода в ThoughtWorks д-р Парсонс являлась доцентом компьютерных наук в Университете Центральной Флориды, где вела курсы по компиляторам, оптимизации программ, распределенным вычислениям, языкам программирования, теории вычислений, машинному обучению и вычислительной биологии. В качестве постдокторанта директора Лос-Аламосской национальной лаборатории д-р Парсонс занималась исследованиями в сферах параллельных и распределенных вычислений, генетических алгоритмов, вычислительной биологии и нелинейных динамических систем.
Ребекка Парсонс получила степень бакалавра компьютерных наук и экономики в Университете Брэдли, степень магистра компьютерных наук в Университете Райса и степень PhD в области компьютерных наук в Университете Райса. Она также является соавтором книг «Domain-Specific Languages, The ThoughtWorks Anthology» и первого издания книги «Эволюционная архитектура».
Патрик Куа — независимый тренер технических директоров, бывший технический директор Компании N 26 и бывший главный технический консультант ThoughtWorks, проработавший в технологической отрасли более 20 лет. Свою личную миссию он видит в том, чтобы способствовать росту технических лидеров с помощью индивидуального коучинга, онлайн-семинаров и очных семинаров по техническому лидерству, а также своего популярного информационного бюллетеня Level Up для лидеров в области технологий.
Он является автором книг «The Retrospective Handbook: A Guide for Agile Teams» и «Talking with Tech Leads: From Novices to Practitioners» и предлагает обучение в Академии техлидов The Tech Lead Academy.
Вы можете узнать о нем больше на его веб-сайте patkua.com или связаться с ним в твиттере @patkua.
Прамод Садаладж — директор отдела данных и DevOps в ThoughtWorks, где решает нестандартную задачу преодоления разрыва между профессионалами в области баз данных и разработчиками приложений. Чаще всего он работает с клиентами, чьи запросы в отношении данных особенно сложны и требуют применения новых технологий и методов. В начале 2000-х создал методологию эволюционной разработки реляционных баз данных на основе миграции схем с контролем версий.
Является соавтором книг «Software Architecture: The Hard Parts», «Refactoring Databases», «NoSQL Distilled», а также автором «Recipes for Continuous Database Integration» и продолжает освещать новые идеи, которые приходят к нему и его клиентам.
Нил имеет степень в области computer science Университета штата Джорджия (со специализацией на языках и компиляторах) и дополнительную степень в области математики (со специализацией на статистическом анализе). Он заслужил международное признание как эксперт в области разработки и доставки программного обеспечения, в частности на стыке agile-методологии и программной архитектуры. Нил является автором ряда статей в тематических журналах, девяти книг (и их число продолжает расти) и десятков видеопрезентаций, а также спикером сотен конференций разработчиков по всему миру. Его работы посвящены вопросам программной архитектуры, непрерывной доставки, функционального программирования и инноваций в сфере ПО, а кроме того, у него есть книга, ориентированная на бизнес, и видео на тему улучшения качества технических презентаций. Он является консультантом в сфере проектирования и создания крупномасштабных корпоративных приложений. Если вы хотите узнать больше о сферах интересов Нила, посетите его веб-сайт nealford.com.
Доктор Ребекка Парсонс — технический директор ThoughtWorks, имеющая многолетний опыт разработки приложений для различных отраслей и систем. Ее технические компетенции включают руководство созданием крупномасштабных распределенных объектных приложений, интеграцию разрозненных систем и работу с командами архитекторов. Помимо своей глубокой страсти к технологиям она активно продвигает разнообразие в технологической отрасли.
До прихода в ThoughtWorks д-р Парсонс являлась доцентом компьютерных наук в Университете Центральной Флориды, где вела курсы по компиляторам, оптимизации программ, распределенным вычислениям, языкам программирования, теории вычислений, машинному обучению и вычислительной биологии. В качестве постдокторанта директора Лос-Аламосской национальной лаборатории д-р Парсонс занималась исследованиями в сферах параллельных и распределенных вычислений, генетических алгоритмов, вычислительной биологии и нелинейных динамических систем.
Ребекка Парсонс получила степень бакалавра компьютерных наук и экономики в Университете Брэдли, степень магистра компьютерных наук в Университете Райса и степень PhD в области компьютерных наук в Университете Райса. Она также является соавтором книг «Domain-Specific Languages, The ThoughtWorks Anthology» и первого издания книги «Эволюционная архитектура».
Патрик Куа — независимый тренер технических директоров, бывший технический директор Компании N 26 и бывший главный технический консультант ThoughtWorks, проработавший в технологической отрасли более 20 лет. Свою личную миссию он видит в том, чтобы способствовать росту технических лидеров с помощью индивидуального коучинга, онлайн-семинаров и очных семинаров по техническому лидерству, а также своего популярного информационного бюллетеня Level Up для лидеров в области технологий.
Он является автором книг «The Retrospective Handbook: A Guide for Agile Teams» и «Talking with Tech Leads: From Novices to Practitioners» и предлагает обучение в Академии техлидов The Tech Lead Academy.
Вы можете узнать о нем больше на его веб-сайте patkua.com или связаться с ним в твиттере @patkua.
Прамод Садаладж — директор отдела данных и DevOps в ThoughtWorks, где решает нестандартную задачу преодоления разрыва между профессионалами в области баз данных и разработчиками приложений. Чаще всего он работает с клиентами, чьи запросы в отношении данных особенно сложны и требуют применения новых технологий и методов. В начале 2000-х создал методологию эволюционной разработки реляционных баз данных на основе миграции схем с контролем версий.
Является соавтором книг «Software Architecture: The Hard Parts», «Refactoring Databases», «NoSQL Distilled», а также автором «Recipes for Continuous Database Integration» и продолжает освещать новые идеи, которые приходят к нему и его клиентам.
Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Архитектура
