QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Пятитомник по архитектуре [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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

Никто не заставляет воспринимать их как постулат или аксиому, никто не заставляет впиховывать невпихуемое

Эххх....

Лично мне они только помогали и упрощали жизнь.

Мне они тоже помогали, я просто не знал, что я только что применил какой-то паттерн)

А так подборка годная. Вечером буду сохранять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

едиснтвенное что их объединяло — они все умели держать марку.

В этом и заключается последствие ошибки украинских интервьюверов.

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

Вроде того. Есть продукт, над которым вы работаете — спрашиваете, как кандидат его бы реализовал от и до, обсуждаете решения, подводные камни, технические тонкости (на этом этапе как раз великолепно проверяется знание матчасти). Неважно, аутсорс это или продукт. Вы ищете человека на проект, над которым он будет плодотворно работать, вот он и должен сходу показать понимание, как это все устроено, работает. А если у него есть еще в загашнике парочка кулсторей в тему и он их рассказал — то это вообще вах вах вах. Давно пора избавляться от университетского прошлого.

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

и дать оффер на 5к?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Треба взяти відпустку, почитати...

Спасибо, очень полезно.

Спасибо.
У меня GoF в epub (а не этих ваших богомерзких pdf) есть. Могу расшарить, если кому нужно. Читать удобней.

Подписаться на комментарии