Книга: Чистая архитектура. Искусство разработки программного обеспечения - Роберт Мартин

Здесь не будет большого количества технической информации, но эта книга прекрасно подходит для того, что бы "въехать" в архитектуру, иметь представление об общих понятиях и возможных проблемах, которые можно решить с помощью чистой архитектуры.

Мне показалось забавным в книге то, что в течении всех глав Роберт Мартин рассказывает о своем опыте и тех решениях, к которым он пришел сквозь годы опыта, но в книге есть глава, написанная другим автором (Симоном Брауном) в 2017 году, и ее содержание примерно такое– "Все советы данные Робертом конечно классные, но вот что я думаю на этот счет..." и показывает доработанные и совмещенные решения, которые ранее описывал Роберт Мартин.

Книга читается легко, после неё можно переходить на более конкретную "хардовую" книгу паттернам и архитектуре на том языке, на котором вы разрабатываете. В данной книге есть код, C и Java, все в целом понятно и без знания данных языков, но Роберт подробно описывает происходящее в данных примерах. Следовательно, уметь читать данный код не обязательно.

Могу смело рекомендовать к прочтению :)

Но перед чтением поймите, что в этой книге не будет конкретики. За все время был только 1 отрывок реального кода. Остальное - это UML-диаграммы. Это неплохо. Просто будьте к этому готовы, что книга очень теоретическая.

ОЧЕНЬ много воды, историй из 60х, 80х, 90х... Если бы все они были в конце книги как приложение, то окей, а так сомнительно.

Часто КРАЙНЕ не хватает примеров кода, ну, чтобы эта книга была полезной с практичной точки зрения.

Не скажу, что я прочитала все книги этого мира, но не ужели нет лучше? Почему именно ее так рекомендуют я не понимаю)

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

В общем, это было крайне утомительно, лекции Мартина забавные и наталкивают на хорошие мысли, но эта книга не удалась, либо ее надо было называть иначе

Если вы ещё не знакомы с литературой по архитектуре, то можете прочитать эту книгу, возможно узнаете про какие-то базовые концепции, но если вы ищете что-то продвинутое, с конкретными советами, то эта книга вам ничем не поможет

В "Чистой архитектуре" надеялся тоже поднять свой уровень, но, увы, примеры показались слишком бек-ендовые и было сложно сообразить как я могу это всё применить у себя на front-end. Т.е. в целом, как front-end я разочарован, но оценка нейтрально 3, потому что другие программисты возможно смогут найти книгу более практичной и применимой. Принципы SOLID описаны лучше чем во многих первых попавшихся статьях из google, время покажет смогу ли я их применить в своей области. Частично книга автобиографична, наверное я бы тоже отнесся к истории автора с большим восторгом, если бы весь остальной контент был понят и переварен, но в моём случае эти вставки не показались сильно интересными.

Поэтому если кому-то и рекомендовать, скорее это бек ендер, и скорее всего с каким-то опытом работы с реальными проектами, иначе боюсь примеры покажется так же далеки как и мне.

И конечно фирменный отвратный перевод на русский. Вместо устоявшихся терминов "фича", "юзкейс" — особенность и случай использования. И т. п.

Но есть и ряд положительных инсайтов:

1. Хорошо показана идея направления зависимостей и изоляции между компонентами (всегда от низкоуровневых к высокоуровневым) 2. Показана роль архитектора, который должен найти этот баланс между идеальной изоляцией компонентов и простотой реализации. Для каждого конкретного случая. 3. Хорошо показано почему архитектурные границы системы не должны совпадать с инфраструктурными (отдельный микросервис != отдельный модуль). Нередко границы проходят по микросервисам и т. п. 4. Убедительно показано почему БД это деталь реализации и почему вредно вокруг нее строить бизне-модель приложения. 5. Надо отличать дублирование архитектуры от псевдодублирования (когда компоненты совпадают случайно и скорее всего будут развиваться независимо друг от друга). Агрессивно искоренять псевдодублирование на ранних этапах очень опасно (потом будет очень сложно раздублировать обратно). 6. Хороший архитектор как можно больше решений откладывает на потом (чем позже принимается конкретное архитектурное решение, например какую БД или формат файла использовать, тем больше информации для принятия хорошего решения).