Пятитомник по архитектуре [POSA]

На просторах интернета лежит книжица по архитектуре, кажись, за границей известная. Первый том вышел через год после Банды Четырех [GoF]. Покрытие архитектуры глубже: если GoF в основном описывает модули, то POSA начинается с вариантов общей структуры приложения, и затем уходит в детали. Дальше небольшая ревьюшка.

Pattern Oriented Software Architecture

Требования к читателю:
* читать после GoF www.sugardas.lt/~p2d/books/Priemioop.pdf
* базовое представление о потоках, процессах, и сетях
* какое-то понимание синтаксиса С++ и Java

Кому пригодится:
Целевая аудитория — архитекторы и синьоры (те, кто занимается созданием и поддержкой структуры системы). При этом язык очень простой, не перегружена деталями. Поэтому хорошо подойдет как учебник по архитектуре приложений и программных систем новичкам, интересующимся этой областью.
По областям — скорее С++, энтерпрайз (если интересно, какое оно под капотом) и эмбеддед.

Что описывает:
Дао создания распределенных, многопроцессных и многопоточных систем с картой некоторых дорожек между граблями. Особое внимание уделяется пользе и цене каждого подхода, соответственно — в какой ситуации стоит применять. Паттерны приведены с кучей вариаций и взаимосвязей для создания общей картины.

Годы выпуска: 1996 — 2007

По томам:

Volume 1: A System of Patterns — База, которой нет в GoF — от Layers и MVC до Blackboard и Microkernel. Must Read.

Volume 2: Patterns for Concurrent and Networked Objects — Построение многопоточных/многопроцессных/распределенных систем, от базовых Reactor/Proactor/Active Object до Half-Sync/Half-Async и Leader/Followers. Примеры сильно overengineered, но полезной инфы масса.

Volume 3: Patterns for Resource Managements — Совсем базовые Pooling и Caching. Более интересные Leasing и Evictor. Скучновато. Бонус — описание системы мобильного оператора.

Volume 4: A Pattern Language for Distributed Computing — Повторение — мать учения. Начинается с 200 страниц подробного описания архитектуры кровавого управления складами, на следующих 400 страницах описаны 100+ паттернов по 2-3 страницы на штуку и упомянуты еще 100+ с кратким описанием по абзацу. 60% из них потянуты из предыдущих томов, остальные — из Фаулера и каких-то публикаций. Рекомендую читать, возможно — сразу после первого тома.

Volume 5: On Patterns and Pattern Languages — Философия о том, как прострелить ногу из паттерна, как паттерны взаимодествуют друг с другом в коде, почему роботы не заменили программистов, и куча разных ссылок на книжки. Некоторые главы можно читать.

Лежит: ff.tu-sofia.bg/~bogi/knigi/SE

P.S. Там же лежит первая книга по антипаттернам, с картинками!

P.P.S. Монография о том, во что превращается код при протухании, как это происходит, и что делать, если не нравится www.laputan.org/mud

P.P.P.S. Архив ежегодной конференции по паттернам. Можно копать от забора до обеда. hillside.net/...op-conference-proceedings

Теми: архітектура

Ctrl + Enter

Леголас Трандуилович 11.08.2019 14:34

Спасибо, отличная энциклопедия. Сам осилил только второй том.

Відповісти

Підтримати

Олексій Пєніє 10.08.2019 10:26

Высшая степень бюрократического долбо§бизма.
ЗАЧЕМ создавать паттерны, если всё что вы вообще знаете, всё что можете объяснить или понять — является паттерном? Но нет, надо ж было собрать кучку... выросшую в пятитомник, чтобы заново изобретать... язык?

Bot Bot 10.08.2019 14:23

Лично я воспринимаю паттерны как классическое решение классической проблемы, просто успешный опыт от опытных профессионалов.
Никто не заставляет воспринимать их как постулат или аксиому, никто не заставляет впиховывать невпихуемое и прочие проблемы о которых постоянно пишут.
Лично мне они только помогали и упрощали жизнь.

Олексій Пєніє

anonymous 10.08.2019 14:28

Bot Bot

Олексій Пєніє 11.08.2019 12:59

Разумеется. И даже если бы знал. Но тебя когда-нибудь пытались оценить по ~~знанию~~ вызубриванию формулировок, притом нужно вызубрить «правильную» формулировку, чтобы совпадала с той бамажкой с которой будет сравнивать вопрошающий. Разумеется сам их не применяющий, и что оно по сути его не касается.

Пример: на какие три вида делятся паттерны?
Вы не сможете дать «правильный» ответ, если только вам его не продиктовали на курсах компании. Потому что правильный ответ — паттерны не делятся. Они могут быть обобщены, опять же ПАТТЕРНОМ. И это обобщение всякий раз будет временным — полезным только для обучения, но не для применения.

anonymous

Vadim Kopanev Architect 11.08.2019 13:39

Пример: на какие три вида делятся паттерны?
Вы не сможете дать «правильный» ответ, если только вам его не продиктовали на курсах компании. Потому что правильный ответ — паттерны не делятся

практически все имеет какую-то классификацию, не придумывай ерунду, берешь что угодно и группируешь по какому-то признаку

Олексій Пєніє 12.08.2019 10:43

ВОТ ИМЕННО!
Но дать-то надо «правильный» ответ, совпадающий с тем что в бумажке у вопрошающего.

Vadim Kopanev

Vadim Kopanev Architect 12.08.2019 14:57

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

Олексій Пєніє 12.08.2019 16:54

Уточнить можно у того кто ЗНАЕТ мат.часть, а не просто ВЫЗУБРИЛ умные слова.

Vadim Kopanev Architect 12.08.2019 18:53

если не адекватный, то хорошо что туда оффер не дадут

Олексій Пєніє 11.08.2019 12:55

Именно! Это лучшие практики, применимые только там, где они применимые. И нигде все сразу, и даже 20% в одном проекте не найдёшь. Потому что всем практикам своё время и место.

Есть БАЗОВЫЕ, их можно пересчитать по пальцам одной руки. Есть типичные для порождения типовых моделей. Есть редко используемые. Есть ДЕГРАДИРУЕМЫЕ, когда это просто поведенческие шаблоны, и они не нуждаются в абстрагировании.

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

ВЫЗУБРИВАНИЕ этого идиотизма напоминает образование программистов в Совке в ранние 90-е годы: их заставляли учить двоичную систему наизусть, «лучшие» знали таблицу до 1024. Хотя полезность этого навыка ушла вместе с перфокартами, и даже тогда была сомнительной.

А знаете ЗАЧЕМ на самом деле это учат? Потому что это ЛЕГЧЕ СПРОСИТЬ. Настоящие знания у людей сильно разные, очень часто меняются по мере применения. А вот бесполезные — можно копипастить сколько влезет. Почему люки круглые? Почему у собаки 4 ноги? Как должен работать паттерн Visitor? И никогда не спросят, что делать если Visitor должен быть нескольких типов, и выполнить несколько разных функций — потому что это потребует ПОНИМАНИЯ паттерна тем кто задаёт вопрос. А не просто сравнения ответа с тупорылой методичкой.

Если кратко, паттерны это карго-культ и только в таком виде существуют в типичном украинском IT. Там где они есть в нормальном применении, о них НЕ ГОВОРЯТ. Потому что там не о чем говорить.

Vadim Kopanev Architect 11.08.2019 13:37

Если кратко, паттерны это карго-культ и только в таком виде существуют в типичном украинском IT

в украинском айти есть еще один карго-культ: «паттерны — очень плохо»

anonymous 11.08.2019 13:54

Vadim Kopanev Architect 11.08.2019 14:03

Может быть потому что на собеседованиях спрашивают о паттернах, которые повторили сами за день до этого, а на самом проекте — говнокод на говнокоде говнокодом погоняет?

не знаю как это связано

Плюс никто не дает исправить нормально ибо "времени нет".

если есть время чинить баги годами, то и на это время есть, достаточно проявить настырность

anonymous 11.08.2019 14:17

Vadim Kopanev Architect 11.08.2019 16:31

каждый сам выбирает свой путь, если нравится говно месить, то конечно то что ты описал идеально

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

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

anonymous 11.08.2019 17:19

Vadim Kopanev Architect 11.08.2019 17:24

дело именно в сыкливости, мне все равно кто чей кум и кто кому начальник, терять-то нечего, работа с тупым начальством не представляет никакой ценности, все же знают — сила в правде :)

anonymous 11.08.2019 17:29

Vadim Kopanev Architect 11.08.2019 17:41

где-то да, где-то нет, очень много факторов влияет

Bot Bot 11.08.2019 14:06

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

Еще кумарят головоломки из эпичнейшего говнокода на JS, в стиле вот смотри месиво из скобочек и замыканий — что выведется в консоль??? Но эти хотя бы сразу, хоть и косвенно, показывают что у них там на проде ))))

anonymous 11.08.2019 14:19

Dmitriy Miekh 11.08.2019 17:43

Итого: паттерны не спрашивать, ибо их никто не использует и они не нужны, фреймворки не спрашивать, ибо есть дока и никто не запоминает их апи, нахождение ошибок и умение разбираться в говнокоде не спрашивать, ибо вообще зашквар, логические задачки не задавать, ибо вы тут не гугл, тестовые задания не давать, ибо час моей работы стоит больше всей вашей компании. Я правильно понимаю, что единственный правильный способ собеседовать великого украинского синьора — это поговорить с ним за жизнь 10 минут и дать оффер на 5к?

Vadim Kopanev Architect 11.08.2019 17:56

Я правильно понимаю, что единственный правильный способ собеседовать великого украинского синьора — это поговорить с ним за жизнь 10 минут и дать оффер на 5к?

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

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

Dmitriy Miekh

anonymous 11.08.2019 19:29

anonymous 11.08.2019 19:27

Bot Bot 11.08.2019 22:21

Для начала нужно определиться кого вы ищете, для каких задач и каких. обязанностей, потом исходить из того что вы ждете от кадра, потом в беседе за пару часов вам надо определить насколько он будет справляться с такими задачами, можно просто начать разговор делал ли кандидат что-то подобное и/или как он собирается решать планиуремые задачи...Ниже/выше более подробно уже расписали.Но такие интервью проводить уметь надо и это отдельный скил у технаря.

Сейчас собесы это просто тупой способ задрочить кандидата чем только могут интервьюверы лишь бы сбить цену или просто почесать свое чсв.

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

Ivan Boyaryn Senior Big Data Engineer в Ciklum 14.08.2019 22:02

Варіант — перевіряти не знання назв і невизначальних деталей, а знання засобів, якими можна зробити задачу, і загальне розуміння того, як воно працює.

Якщо інтерв’юер працює на проекті, куди Вас співбесідують, по питаннях часто можна зрозуміти, наскільки погана чи хороша ситуація на проекті і чи компанія потягне Ваш рейт. :-)

Олексій Пєніє 12.08.2019 10:41

Нет такого. Зато есть эпичнейшее непонимание, КАК строятся абстракции, и почему за каждой абстракцией должен стоять паттерн — иначе код нечитабельный.

Вот только паттернов явно больше, чем те что описаны в пятитомнике. А те что описаны — 4 из 5 и за жизнь не встретишь в реальном коде. Разве что в старом.

Denys Poltorak Embedded | C++ (opentowork) 12.08.2019 11:58

Буч пытается написать Handbook of Software Architecture. В 2007 у него было порядка 2К паттернов.
(До сих пор не дописал)

Олексій Пєніє 12.08.2019 15:00

Он просто Ctrl-C — Ctrl-V стесняется. А вот писал бы диплом в нашем универе...

Denys Poltorak

Володимир Корнійчук Senior Software Engineer (C++) в Infopulse 14.08.2019 10:36

Який сенс в книзі з описом 2к паттернів? Хто її прочитає? Хто з них хоча б 10% запам’ятає?

Denys Poltorak Embedded | C++ (opentowork) 12.08.2019 11:49

Ты только что пересказал первую часть пятого тома)

Олексій Пєніє 12.08.2019 12:03

Сейчас скажу что первые 4 можно не читать — и это будет вторая часть 5-го тома :)

Denys Poltorak Embedded | C++ (opentowork) 12.08.2019 12:29

Примеры из моей жизни:

1) Вот сейчас телефонию доделываю (шлюз между SIP и DECT). Как положено, объект звонка, у него инициатор и адресат, номер звонящего и имя звонящего, чтобы можно было показать на экране трубки, на которую звонок приходит. А потом, через 2 года в продакшне, новое требование: если есть звонок на удержании, и пользователь кладет трубку — надо перезвонить обратно пользователю (в принципе, разумно — он мог забыть про этот звонок). И красивая картинка разваливается — оказывается, когда пользователь позвонил куда-то, поставил на удержание, и положил трубку — у звонка вдруг 2 адресата, вместо номера звонящего надо показать набранный номер, откат назад по life cycle, и еще правильно залогировать это все. В общем, пару месяцев нервов, но сделал. А сейчас начал смотреть старые конфы по паттернам — и наткнулся на Half-Call. Идея в том, что нет объекта звонка, а есть половинки, из которых собираются обычные звонки, их можно перекомпоновывать, даже конфу делать из 3-х половинок. И вот это реально все разрулило бы, если бы знал раньше, и без нервов и кучи багов. Хоть и контринтуитивно.

2) 10 лет назад, когда кризис, и радиотелефоны не продаются, народ почухался и выдал стандарт CAT-iq 2 с блекджеком и параллельными звонками. Чтобы типа мобильные догнать. Не помогло. Но стандарт был (и есть) кривой и сырой. Ну я свою трубку подтянул, захожу к соседям — они грустные сидят, еще и тимлид свалил. Порасспрашивал, че да как — у них Actors, а в стандарте сильно много запутанной логики, асинхронно (Actors) столько логики не натянешь, оперативы 2 киловорда, и че делать — неясно. В общем, начали рисовать, предложил вынести всю логику в центрального жирного актера, а в остальных оставить только прослойку, работающую с железом. Народ поржал, но ничего лучше не придумали. Начальство в израиле посмущалось, но тоже никто ничего не предложил. Потом месяц рисовали диаграммы последовательностей, чтобы убедиться, что оно сработает. Потом еще месяц кодили. Вот это все во втором томе есть (Half-Async/Half-Async), и не надо было столько думать, а можно было сразу трясти, так как схема известная и рабочая. Но никто из нас ни о ней не слышал, ни о пятитомнике.

Ну и для аргументации начальству, думаю, умные названия и толстая книжка — самое оно. Например, недавно линк на Death March на вики пригодился.

Олексій Пєніє 12.08.2019 15:17

Телефония для меня вообще адский ад. КАК МОЖНО было наворотить такой идиотизм, и считать это стандартами?
Правильные стандарты — это в объектном программировании. Вот тебе объекты, вот чего можно с ними делать, вот тебе процесс — и это тоже объект. Вот тебе потоки — это объекты.

Телефония — это п****ц. Вот тебе НЕЧТО, что есть чёрный ящик, вот тебе инструкции, которые выполняются не одна за другой, а хер пойми в какой последовательности — одна инструкция начнёт выполняться и будет ждать, а другая — запустит НЕЧТО и пойдёт выполняться следующая. И это НЕЧТО может и закончит работу, а может уйдёт на удержание — и хер пойми как за этим следить.

Особое мудачество — переменные. Это даже не 90-е, это 80-е. Что значит переменная v? А в каждом конкретном случае своё. И чтобы до неё добраться, прочитай страниц 40 документации, наполненного тем же дерьмом. И нет ничего, названного по-человечески, даже если ставишь четвётрый слой софтовых надстроек — всё равно там будут галочки KJEJLL, answRLLLOQ, выбор между QENDI и MRITTzx, и по всему этому документация, объясняющая что угодно, кроме значения этих краказябл.

Ладно, в чём измеряется время. В секундах? Нет. В милисекундах? Нет. До версии 87.1 в милисекундах, до версии 66.6 в микросекундах, после версии 90.6 в секундах, но в 90.6.1 и 90.6.Х в милисекундах при входящем звонке из зоны 4 и 5. — а теперь УГАДАЙТЕ, при куче разной документации, УПОМЯНУТО ЛИ к какой версии писана каждая статья, при том что известно что писались они в разное время. Особенно когда сайт с первоисточником сдох, и приходится читать копипасту.

Команды ЖДИСУКА, пока не завершится предыдущая — нет. И т.д., и т.п.

Я не нашёл иного решения, кроме как ВНЕШНИМ приложением управлять всем этим дерьмом, и ещё поднимать циклы обслуживания, проверяющие а не зависло ли чего. И всё равно падла хоть раз в пару месяцев, но чего-нибудь зависнет, чего-нибудь застрянет, чего-нибудь не соизволит подать сигнал приложению...