Нон-фикшн (хочу прочитать)
Anastasia246
- 5 193 книги

Ваша оценкаЖанры
Ваша оценка
Отвратительный перевод, не ожидал такого от «Питера». Суть книги раскрывает этот абзац из начала шестой главы:
Многие концепции, которые мы обсуждаем в этой книге, не являются новыми идеями. Например, тестирование существовало многие годы, но без функций пригодности, делающих акцент на проверку архитектуры.
Поставил бы двойку, но есть полезная глава про ловушки и антипаттерны архитектуры, с таким искренним пунктом, как «Разработка ради резюме»: Разработчики используют фреймворки и библиотеки, чтобы рекламировать эти знания в своем резюме.

Перевод очень плохой. Первые две главы читабельны, но дальше наступает такой ужас, что легче переводить онлайн-переводчиком. Существует второе издание этой книги, а также его перевод на русский язык (ISBN: 978-601-08-3643-3), возможно он будет лучше, чем этот.
Книга очень полезная. Особенно удачной получилась седьмая глава с её ловушками и антипаттернами. Не отстает от неё и пятая глава с описанием шаблона безопасного обновления схемы базы данных, которую одновременно используют несколько сервисов. Это особенно полезно для тех, кто проектирует архитектуру с нулевым временем простоя и применяет механизм rolling upgrade для поэтапного обновления сервисов. А восьмая глава просто выдает базу от том, что достижение эффективной масштабируемости невозможно без уменьшения связанности, и квантование монолита избавляет от необходимости поиска компромисса между антогонирующими архитектурными свойствами.
Несмотря на это, есть в книге моменты, с которыми я не согласен и которые вызывают у меня негативные ощущения.
Автор предлагает спорную классификацию архитектурных стилей.
В четвертой главе автор описывает несколько архитектурных шаблонов: ESB-driven SOA, Service-Based Architectures и Microservices, которые он относит к сервис-ориентированным архитектурам. На самом деле сервис-ориентированная архитектура (SOA), архитектура на основе сервисов (SBA) и микросервисная архитектура (MSA) это совершенно разные архитектурные стили. Идеология SOA, централизация управления с целью максимального переиспользования кодовой базы, полностью противоположна идеологии микросервисов, проповедующей децентрализацию и достижение максимальной независимости даже ценой дублирования кода.
Автор размывает разницу между терминами coupling и cohesion.
Coupling характеризует только внешнюю зависимость между модулями, в данном случае между слоями. За обозначение внутренней связности отвечает cohesion. Поэтому вместо "high internal coupling" следовало бы написать "high cohesion". А в фразе "low external coupling" слово "external" лишнее.
Автор размывает разницу между оркестрацией и хореографией.
Например, в контексте описания ESB-driven SOA он пишет и изображает на рисунке 4-10, что сервисная шина занимается оркестрацией и хореографией.
В тексте хореография и оркестрация объединены так, как будто это схожие или одновременно выполняемые функции ESB. В действительности они представляют собой два разных и часто противоположных паттерна интеграции. Оркестрация - это централизованный процесс. Один центральный компонент (оркестратор, который часто является функцией ESB) управляет бизнес-процессом, вызывая различные сервисы в определённом порядке и обрабатывая логику. Это похоже на дирижёра, который указывает каждому музыканту, когда играть. Хореография - это децентрализованный процесс. Здесь нет центрального контроллера. Каждый сервис знает, что делать в ответ на получаемые сообщения, и публикует события, которые могут прослушивать другие сервисы. Это похоже на группу танцоров, которые знают свои шаги и реагируют на движения друг друга без дирижёра. ESB — это в первую очередь инструмент для оркестровки. Хотя она может облегчать взаимодействие в системе, построенной по принципу хореографии, её главная сила и предназначение — выступать в роли центрального контроллера. Поэтому представлять их вместе как единую ответственность логически некорректно.
Автор вводит читателя в заблуждение при описании архитектуры, основанной на сервисах (Service-Based Architecture).
Это утверждение не корректно, так как в Service-Based Architecture (SBA) сервисы не обязаны использовать сервисную шину. Это отличает Service-Based Architecture от классической Service-Oriented Architecture. SOA направлена на интеграцию разнородных сервисов, поэтому ESB является её ключевым признаком. SBA направлена на дробление монолита, поэтому сервисы в этой архитектуре однородны, а следовательно им не нужна высокоинтеллектуальная интеграционная шина.
Автор навязывает читателю спорное утверждение о версионировании исходного кода и миграций схемы базы данных.
Здесь автор говорит, что исходный код приложения и миграции схемы базы данных нужно версионировать вместе. Причем он осуждает инженерные практики, которые разделяют эти процессы. Складывается впечатление, что автор настаивает на хранении миграций и кода в одном репозитории. Я считаю, что это очень неудачное решение. Очевидно, что не каждая новая версия исходного кода требует внесения изменений в схему базы данных. С другой стороны, не всякое изменение схемы должно приводить к изменениям в исходном коде. Например, в базах данных часто ограничивают длину текстовой строки, но со временем приходится расширять это ограничение, чтобы в таблицу поместилось какое-то новое значение. В современных языках программирования память для хранения строк выделяется динамически, поэтому зеркалить изменение схемы в исходном коде не потребуется. Если связать исходный код и миграции в одной единице развертывания, то всегда придется обновлять схему базы данных и приложение вместе, вне зависимости есть ли на то необходимость или нет, что безосновательно повышает эксплуатационные расходы.
Автор намеренно подталкивает читателя пренебрегать функционалом отката при создании миграций схемы базы данных.
Возможность откатить изменения схемы базы данных похожа на страховку. Каждый релиз вы платите небольшими затратами времени на создание механизма отката, надеясь, что он никогда не понадобится. Но если вдруг ваш новый релиз положит прод, вы сможете компенсировать всё это потраченное время быстро вернувшись к предыдущей работоспособной версии приложения, чтобы разобраться с проблемой в штатном режиме без переработок и давления руководства.
Автор забывает раскрыть заявленную тему двухфазной фиксации.
В пятой главе автор высказывает идею о том, что границы микросервисов должны проходить по границам транзакций, так как транзакционная связность является самой сильной формой связности. Из этого автор делает вывод, что для сильно транзакционной предметной области мелкогранулированная микросервисная архитектура может принести только вред. В целом, автор излагает правильные мысли, но где, черт-побери, двухфазная фиксация? Кроме как в заголовке автор больше ни разу не упоминает двухфазную фиксацию. В принципе можно было бы догадаться, что транзакции с двухфазной фиксацией - это и есть тот самое зло, которое несет неадекватно мелкое разбиение на микросервисы сильно транзакционной предметной области, но читатель платит деньги, чтобы прочитать этот вывод в книге, а не строить свои догадки.
Автор уходит от темы эволюционной архитектуры в рефлексию над сложностями интеграции с коммерческим программным обеспечением.
Здесь автор ноет, что покупателям коммерческого программного обеспечения трудно обеспечить его эволюционное развитие: и изменения у него не инкрементальные, и связность необоснованная, и функцию пригодности сложно написать. А бывает, что у такой системы точкой интеграции служит база данных, и в этом случае автор предлагает отнять у этой системы контроль над базой данных. Мне вот только не понятно, как автор собирается объяснять покупателю коммерческой системы, что система, которую он купил, не работает, потому что автор решил, что у этой системы слишком много контроля над базой данных. И вообще, зачем автору понадобилось применять практику построения эволюционных архитектур для программного обеспечения, которое автор не разрабатывает, а тупо покупает готовым?
Автор ошибается в описании шаблона abstraction distraction.
Это не правда. Термин “abstraction distraction” используют в разработке ПО для описания ситуации, когда разработчики увлекаются созданием абстракций ради самих абстракций, а не ради решения реальной задачи.
Автор ошибается в описании концепции порождающего тестирования.
Порождающее тестирование не предполагает статистический анализ результатов для выявления аномалий. Что нам даст информация о том, что в 1% случаев код работает неправильно? Нам важно знать конкретный набор входных данных, сгенерированных тестом, на которых возникла ошибка.

Книга в целом неплохая (хотя конкретики маловато). Перевод ужасный, больше путает, чем помогает понять.

Amazon realized that coupling everything to one thing (whether a relational database, enterprise service bus, and so on) ultimately limited scalability. By redesigning their architecture in a more microservices style that eliminated inappropriate coupling, they allowed their overall ecosystem to scale.
A side benefit of that level of decoupling is enhanced evolvability. As we have illustrated throughout the book, inappropriate coupling represents the biggest challenge to evolution. Building a scalable system also tends to correspond to an evolvable one.

















