book covers Не знаю как, но эти две книги прошли мимо меня в своё время: они вышли в 2020 и 2022 годах. До их прочтения для меня единственной «фундаментальной» книгой про архитектуру ПО была «Чистая архитектура» Роберта Мартина. Крайне opinionated взгляд автора породил какое-то неимоверное количество холиваров, которые не утихают до сих пор. Можно по-разному относиться к конкретным советам автора, но чего не отнять, так это то, что люди массово начали хотя бы задумываться над тем, как они пишут софт.

От этой дилогии же исходит более спокойный архитекторский вайб. Но не тот, от которого хочется «открыть форточку», а который пытается передать эссенцию проблемы проектирования – «во всём есть компромисс».

Порядок чтения

Сперва стоит прочитать «Fundamentals», а уже потом переходить к «Hard Parts», т.к. авторы будут ссылаться из второй книжки на первую. Также есть отсылки к книге Форда «Building Evolutionary Architectures», но её читать перед ними не обязательно.

Fundamentals of Software Architecture. An Engineering Approach

Всё начинается с того, чтобы объяснить разработчику, который хочет стать архитектором, в чём будет отличие в работе и способе мышления на новой позиции.

Если после всего прочитанного он не передумает, то дальше его ждут самые зубодробительные главы книги: модульность, архитектурные характеристики, управление через метрики. Авторы тут копают достаточно глубоко, и местами абстрактность улетает в космос, но тут спасают примеры в виде архитектурных упражнений по типу тех, что дают на секциях System Design при собеседованиях.

Далее разговор заходит об архитектурных стилях: от слоистого монолита до микросервисной архитектуры. Каждый из стилей детально просматривается через призму компромиссов, которые есть в каждом из них. Приводятся примеры задач, которые лучше всего покрываются тем или иным стилем. Задача этого обзора – скорее натренировать критический взгляд на вещи, чем в сотый раз описывать конкретные подходы к архитектуре. Поэтому даже если вы знакомы с этими стилями, то пропускать этот раздел не стоит. Также тут не стоит искать советы по применению тех или иных фреймворков или middleware. Эта книга именно про становление подхода к архитектурному мышлению, а не справочник по реализации.

Заканчивается эта 400 страничная книга уже конкретными советами по «человеческой» стороне работы архитектора: как доносить архитектурные решения. Работа с командами, оформление артефактов, лидерство и переговоры – без этих навыков современный архитектор будет крайне неэффективен.

Буду честным. Эту книгу я прочитал не без усилий над собой. Благо читал её будучи в отпуске, и меня ничего не отвлекало лишний раз от чтения часами. Не скажу, что узнал из неё много нового, но она точно достойна того, чтобы её прочитать хотя бы раз даже сеньору. Ну а если вы ещё неопытный разработчик, но с архитекторскими амбициями, то, чтобы «переварить» её, вам придётся прочитать её не один раз :)

Software Architecture: The Hard Parts. Modern Trade-Off Analyses for Distributed Architectures

После некоторых глав первой книги невольно задумаешься: о каких ещё «hard parts» может быть речь? Куда уж сложнее! В введении авторы пояснили, что помимо базы они хотели дать советы по решению известных архитектурных проблем. Но первая книга получилась и так достаточно большой, и поэтому они вынесли эти темы в отдельную. И выбрали для этого очень креативный подход, который не часто встретишь в технической литературе: бизнес роман. Если вам довелось прочитать бестселлеры типа «Проект Феникс» или книги Элияху Голдратта (например, «Цель»), то вы примерно поймёте, что вас ждёт. Погружаться в сложные темы в формате наблюдения за персонажами, которые в диалогах обсуждают проблемы, намного легче и интересней. Конечно, в этой книге не чистый бизнес роман: вместо воды между сюжетами там обычная подача теории. Так не теряется техническая глубина повествования, а сюжетные сценки – скорее приятное разбавление сухой теории.

Дело разворачивается в вымышленной компании, занимающейся сервисным ремонтом техники. Её бизнес страдает от того, что айтишники никак не могут справиться со своим неповоротливым и нестабильным монолитом, на котором держится весь бизнес компании. Терпение руководства на исходе, и двум архитекторам поручают привести айтишку в чувство. Согласитесь, достаточно жизненная ситуация. Вызывает неподдельное чувство «I feel your pain, bro». Я не буду спойлерить дальнейшие детали, но могу заверить, что вы вместе с героями пройдётесь по многим больным вопросам, и прочувствуете тему компромиссов ещё глубже. Плохих решений нет, есть неподходящие. Именно в этой книге вы больше всего натренируетесь в применении анализа архитектуры: от способов разбиения кода до синхронизации данных в микросервисах.

Да, эта книжка тоже порядка 400 страниц, но читалась она почти на одном дыхании. К ней определённо стоит возвращаться, когда в работе появляются похожие кейсы.

Приятного чтения!