Комментарии 16
А как так получилось, что под абзацем про 23 паттерна картинка на которой 22 паттерна?
Где порождающий паттерн Строитель (builder)?
Про системных архитекторов очень хорошо рассказывал в свое время Анатолий Левенчук. Были хорошие примеры с атомными электростанциями и реализацией аудио в автомобиле и hifi системах, он просто рассказал что все продумать невозможно и есть необходимость в достаточных компетенциях в реализации проекта в котором используется ряд технологий. На курсах связанных с софтверной реализацией по сути перечисляют актуальные на данный момент технологии и рассказывают как и для чего это работает. Почему нет курсов, которые просто расширят кругозор и покажут нетипичное использование и частые антипаттерны, например сейчас очень часто видно реализации распределенного монолита, который все называют микросервисной архитектурой.
Работа Брукса «Мифический человеко-месяц, или Как создаются программные системы» до сих пор считается классической.
И чем дальше, тем классичнее будет - это в одну сторону работает.
Архитектор нужен для компаний, разработчиков десктопных приложений. Для компаний разработчиков веб решений архитектор необязателен, можно спокойно пилить на MVC фреймворке с горизонтальным масштабированием системы и быть счастливым. В десктопе так не получится.
Message Broker был реализован в виде полноценных внешних систем вроде RabbitMQ или Apache Kafka
Это совсем не брокеры сообщений. Потому что в той же книге и написано
" Довольно часто внутри брокера сообщений используется каноническая модель данных (Canonical Data Model, с. 367), позволяющая избежать знаменитой проблемы ‘‘N2 ’’ (с увеличением числа получателей системы число трансляторов, необходимое для преобразования сообщений между каж дой парой получателей, растет в квадрате) "
Это совсем другой уровень абстракции, которого у "кролика" и не предполагалось.
Поэтому очередь сообщений может быть частью брокера, но скорее так и останется просто удобным транспортом. Возможности по маршрутизации того же RabbitMQ более чем скромны.
Как часть ESB запросто, но он будет полностью под капотом и вы знать не будете, что там маршрутизация выстроена по заголовкам или каким-нибудь хэшированным условиям. Ключи не годятся из-за их антикоммутативности. Т.е. маршрутизация в терминах БЛ будет переведена на язык маршрутизации очередей и в общем это все не самое удачное решение.
Вы путаете два типа архитекторов. Архитектор - как должность, и архитектор - как роль.
Как должность архитектора может вообще не быть (или быть десяток в зависимости от штатного расписания), и что он делает, определяется его должностной инструкцией (может вообще ничего не делать).
А вот архитектор - как роль, есть всегда и его задачи очень часто решаются самими разработчиками, и в этом случае выделенный архитектор - как должность может быть не нужен (хотя сами архитектурные задачи никуда не деваются).
Процесс разработки десктопного приложения выглядит так: архитектор разрабатывает структуру приложения, основные классы и основные методы; программист получает задание разработать класс А с основными методами Фу и Бар вместе они должны делать то и то. Программист пишет исходный код класса и тесты. Потом Тимлид компилирует сборку приложения. В этом процессе роль архитектора важна и для серьёзного приложения нужна должность.
В веб разработке процесс выглядит так: ПМ, аналитик, тимлиды и клиент собираются вместе решают что нужно в результате. Результат встречи интерпритируется в ТЗ которое команда успешно превращает в исходный код и компоненты, часто используя фреймворки. В этом процессе системный архитектор не востребован ни как роль, ни как должность и встречается крайне редко. Всё делают разрабы выражая свои знания и умения в коде.
Ну как-то так, но конечно все может быть и иначе.
Тем не менее, архитектурные задачи во втором вашем примере присутствуют. (какой фреймворк и БД использовать, как разбить на компоненты и т.д.). Вот это и есть архитектор как роль, но выполняются эти задачи ПМ, аналитик, тимлид и клиенты совместно, просто они этого не осознают :-)
Мне показалось, что вы не понимаете в чем смысл работы системного архитектора при разработке ПО.
А вот мне кажется, что вы не понимаете в чем суть выделенного архитектора. Выделенный архитектор (пусть не отдельная должность, а только выделенная роль), это в первую очередь персональная ответственность.
Ведь решать архитектурные задачи можно и совместно (как в вашем примере). Но это разделение ответственности, когда все, а по сути - никто не несет ответственность за архитектурные просчеты.
На каком то уровне персональная ответственность - это не то, что может полноценно обеспечивать страховку убытков от неправильных решений персоны. Там уже скорее речь идет не об ответственности, а о предпринимательском риске в виде доверия выбранному бизнесменом (или высшим менеджментом) главному архитектору.
Я говорю о ситуации, когда коллективное решение может рассматриваться как способ избежать ответственности вообще, так как можно выбирать и голосовать за какое угодно предложение.
страховка убытков от неправильных решений персоны
Это зона ответственности менеджера, а не архитектора. Собственно, выбор между "выделенный архитектор" и "коллективное решение", это тоже решение менеджера, которое по хорошему должно быть основано на балансе между возможными рисками и стоимостью.
В веб разработке процесс выглядит так: ПМ, аналитик, тимлиды и клиент
А потом получаем то, что последнее время мы видим во фронте - поддержка этих макарон просто тормозит дальнейший прогресс продукта. Архитектор вовремя не остановил этот балаган и цирк с конями и не сказал "нет", когда ПМ с клиентом перегнули палку и вместили в сроки "невпихуемое" с помощью спецов "React за 21 день" :(
Hidden text
Вспомнил наглядный пример)
Почему компании не нужен архитектор