Нам не нужны модели процессов! У нас и так всё работает!
— услышал я сегодня на интервью с заказчиком.
Проект на технический аудит ИТ-ландшафта. У клиента отягощенный анамнез: 2 конкурирующие платформы в качестве веб-витрины на совершенно разных стеках, разные вертикали управления. В дополнение к этому — отдельная платформа для мобильного приложения. Множество стран с разными требованиями к обеспечивающим процессам: платежные шлюзы, адреса, курьерские службы, ценообразование, и так далее. Значительная доля бизнес-логики упрятана в хранимые процедуры Oracle, time to market страдает, потому что ораклисты вешаются и не успевают.
Работают по принципу «одна команда выпустила фичу, которая сломала три других, завтра эта фича уже не нужна, послезавтра команду уволили, документации нет».
Когда говорят слово «аудит», подразумевают оценку соответствия чего-то чему-то. Применительно к ИТ-системе аудит предполагает, что система удовлетворительно обеспечивает бизнес-процессы компании. Иными словами аудит может быть на полноту функционального обеспечения процессов — например, степень автоматизации. Либо, что чаще — аудит на соответствие нефункциональным требованиям (НФТ).
И тут начинается самое интересное: откуда взять НФТ?
Требования к ИТ-системам выдвигаются со стороны бизнес-процессов; таким образом, чтобы понять что, где и как должна делать система, нужна модель процесса. Модель должна быть настолько подробной, чтобы количественно и качественно выразить требования к ИТ-системе при выполнении шагов бизнес-процесса.
Например, если мы говорим про каталог интернет-магазина, нужно понимать, какое количество наименований товара существует, как товары попадают на витрину. Как устроена проценка, есть ли программа лояльности, влияющая на цены для разных клиентских сегментов. Откуда берутся остатки, как остатки влияют на возможность добавить товар в корзину в зависимости от геолокации клиента или от выбранного способа получения. Можно продолжать очень долго, но главное — без подробных моделей бизнес-процессов не будет обоснованных НФТ к системам.
Технический аудит в этом случае сведётся к чеклисту самых ярких факапов проектирования: вытащите бизнес-логику из хранимые процедур СУБД; распилите монолит на сервисы/соберите зоопарк сервисов в монолит — оба противоположных совета вполне можно обосновать, не имея НФТ и моделей процессов. Уберите дублирование систем аутентификации и авторизации пользователей. Добавьте шардирование СУБД. Перейдите на нереляционные СУБД. Перейдите на реляционную (другую!) СУБД. И так далее — бездумные рецепты, которые можно нагуглить или попросить сформулировать ChatGPT.
Невооруженным глазом видно, что проблема у клиента на организационном уровне: создать и поддерживать конкурирующие платформы, удваивающие операционные расходы, можно только выстроив совершенно неэффективную модель управления и максимально затруднив коммуникацию между группами людей — конечно, я про закон Конвея.
Морали нет никакой. Наверное, надо передать проект тимлиду и потиху уйти с пресейла.
#жиза
— услышал я сегодня на интервью с заказчиком.
Проект на технический аудит ИТ-ландшафта. У клиента отягощенный анамнез: 2 конкурирующие платформы в качестве веб-витрины на совершенно разных стеках, разные вертикали управления. В дополнение к этому — отдельная платформа для мобильного приложения. Множество стран с разными требованиями к обеспечивающим процессам: платежные шлюзы, адреса, курьерские службы, ценообразование, и так далее. Значительная доля бизнес-логики упрятана в хранимые процедуры Oracle, time to market страдает, потому что ораклисты вешаются и не успевают.
Работают по принципу «одна команда выпустила фичу, которая сломала три других, завтра эта фича уже не нужна, послезавтра команду уволили, документации нет».
Когда говорят слово «аудит», подразумевают оценку соответствия чего-то чему-то. Применительно к ИТ-системе аудит предполагает, что система удовлетворительно обеспечивает бизнес-процессы компании. Иными словами аудит может быть на полноту функционального обеспечения процессов — например, степень автоматизации. Либо, что чаще — аудит на соответствие нефункциональным требованиям (НФТ).
И тут начинается самое интересное: откуда взять НФТ?
Требования к ИТ-системам выдвигаются со стороны бизнес-процессов; таким образом, чтобы понять что, где и как должна делать система, нужна модель процесса. Модель должна быть настолько подробной, чтобы количественно и качественно выразить требования к ИТ-системе при выполнении шагов бизнес-процесса.
Модель — это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.—“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans, перевод В.Л. Бродового
Например, если мы говорим про каталог интернет-магазина, нужно понимать, какое количество наименований товара существует, как товары попадают на витрину. Как устроена проценка, есть ли программа лояльности, влияющая на цены для разных клиентских сегментов. Откуда берутся остатки, как остатки влияют на возможность добавить товар в корзину в зависимости от геолокации клиента или от выбранного способа получения. Можно продолжать очень долго, но главное — без подробных моделей бизнес-процессов не будет обоснованных НФТ к системам.
Технический аудит в этом случае сведётся к чеклисту самых ярких факапов проектирования: вытащите бизнес-логику из хранимые процедур СУБД; распилите монолит на сервисы/соберите зоопарк сервисов в монолит — оба противоположных совета вполне можно обосновать, не имея НФТ и моделей процессов. Уберите дублирование систем аутентификации и авторизации пользователей. Добавьте шардирование СУБД. Перейдите на нереляционные СУБД. Перейдите на реляционную (другую!) СУБД. И так далее — бездумные рецепты, которые можно нагуглить или попросить сформулировать ChatGPT.
Невооруженным глазом видно, что проблема у клиента на организационном уровне: создать и поддерживать конкурирующие платформы, удваивающие операционные расходы, можно только выстроив совершенно неэффективную модель управления и максимально затруднив коммуникацию между группами людей — конечно, я про закон Конвея.
Морали нет никакой. Наверное, надо передать проект тимлиду и потиху уйти с пресейла.
#жиза
❤2
Слать в брокер полные JSON или уведомления-квитанции об изменении сущности?
Рекомендую слать полные модели данных через брокеры, разве что у вас есть причины делать иначе.
Например, нам нужно передать изменение статуса заказа из системы для франчайзи-партнеров в систему интернет-магазина. Варианты: (а) слать идентификатор заказа («квитанция»), (б) слать идентификатор и статус, (в) слать полную модель заказа.
Отбросили вариант (в) потому что нет бизнес-требований получать изменения по составу заказа; и хотя они очень скоро появятся, мы предпочтём организовать отдельный поток с полными моделями, а сейчас будем получать идентификатор+статус, то есть вариант (б).
Когда слать «квитанции»
Можно использовать паттерн „claim check“, если модели данных большие по объёму — сотни килобайт или даже мегабайты. Решение надо принимать, оценивая:
(1) Медианное и пиковое количество сообщений в секунду, минуту, час и сутки.
(2) Размер сообщений — более-менее постоянный либо может значительно отличаться, например внутри структуры могут быть коллекции.
(3) Возможности инфраструктуры — Apache Kafka работает по принципу неудаляемого журнала, поэтому нужно учесть рост объема хранилища в течение разумного срока. Год, три, пять лет — нужно предусмотреть что нужно будет наращивать железо. Rabbit MQ обычно удаляет сообщения после доставки.
Плюсы полных моделей:
➕ Адресат получает сразу всю отправленную информацию, не тратит время на обогащение
➕ Отсутствует дополнительная нагрузка на систему-отправитель при запросе «по квитанции»
➕ Упрощает архитектуру и делает систему более надежной, убирая лишние интеграционные потоки
Минусы полных моделей:
➖ Для больших объемов передаваемых моделей требуется много места для хранения очередей
➖ Пока модель ждёт в очереди, состояние оригинала в системе-отправителе может измениться и адресат может выполнить ненужную работу
Наш тимлид страшно любит слать корешки. Я бьюсь каждый раз как демон в пользу полных моделей. У каждого из нас железобетонные аргументы :)
#брокеры #паттерны
Рекомендую слать полные модели данных через брокеры, разве что у вас есть причины делать иначе.
Например, нам нужно передать изменение статуса заказа из системы для франчайзи-партнеров в систему интернет-магазина. Варианты: (а) слать идентификатор заказа («квитанция»), (б) слать идентификатор и статус, (в) слать полную модель заказа.
Отбросили вариант (в) потому что нет бизнес-требований получать изменения по составу заказа; и хотя они очень скоро появятся, мы предпочтём организовать отдельный поток с полными моделями, а сейчас будем получать идентификатор+статус, то есть вариант (б).
Когда слать «квитанции»
Можно использовать паттерн „claim check“, если модели данных большие по объёму — сотни килобайт или даже мегабайты. Решение надо принимать, оценивая:
(1) Медианное и пиковое количество сообщений в секунду, минуту, час и сутки.
(2) Размер сообщений — более-менее постоянный либо может значительно отличаться, например внутри структуры могут быть коллекции.
(3) Возможности инфраструктуры — Apache Kafka работает по принципу неудаляемого журнала, поэтому нужно учесть рост объема хранилища в течение разумного срока. Год, три, пять лет — нужно предусмотреть что нужно будет наращивать железо. Rabbit MQ обычно удаляет сообщения после доставки.
Плюсы полных моделей:
Минусы полных моделей:
Наш тимлид страшно любит слать корешки. Я бьюсь каждый раз как демон в пользу полных моделей. У каждого из нас железобетонные аргументы :)
#брокеры #паттерны
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Двойной асинхрон 🥕🥕
«Парни из того отдела» подбросили кринжа, согласовав интеграционный поток в виде Navision → Apache Kafka → RabbitMQ → Bitrix.
Потому что «мы не можем предоставить вам доступ к эндпоинту Кафки из соображений безопасности». Наш слабый аргумент что в Apache Kafka есть штатный плагин для организации групп доступа ACL потонул в непонимании. «Это долго согласовывать с безопасниками и вообще мы не согласны!»
*звуки давящегося от ярости Андрея*
«— Окей, — говорит наш тимлид. А переложить из своей кафки в нашу рэббит вы можете?
— Конечно можем. Это мы легко!»
В итоге мы имеем двойной асинхрон 🍆🍆💦 в архитектуре.
Почему это плохая идея
Потому что 2 брокера в одном интеграционном потоке — избыточно. Увеличивается количество возможных точек отказа безо всяких плюсов, кроме экономии джоулей на мыслительный процесс безопасников. Увеличивается время передачи данных, хотя в данном случае это не критично — мы передаём модели заказов для истории в личном кабинете клиента.
#жиза #брокеры #антипаттерны
«Парни из того отдела» подбросили кринжа, согласовав интеграционный поток в виде Navision → Apache Kafka → RabbitMQ → Bitrix.
Потому что «мы не можем предоставить вам доступ к эндпоинту Кафки из соображений безопасности». Наш слабый аргумент что в Apache Kafka есть штатный плагин для организации групп доступа ACL потонул в непонимании. «Это долго согласовывать с безопасниками и вообще мы не согласны!»
*звуки давящегося от ярости Андрея*
«— Окей, — говорит наш тимлид. А переложить из своей кафки в нашу рэббит вы можете?
— Конечно можем. Это мы легко!»
В итоге мы имеем двойной асинхрон 🍆🍆💦 в архитектуре.
Почему это плохая идея
Потому что 2 брокера в одном интеграционном потоке — избыточно. Увеличивается количество возможных точек отказа безо всяких плюсов, кроме экономии джоулей на мыслительный процесс безопасников. Увеличивается время передачи данных, хотя в данном случае это не критично — мы передаём модели заказов для истории в личном кабинете клиента.
#жиза #брокеры #антипаттерны
🤯1👻1
Исправление интеграции со СберМаркетом
Описал кейс интеграции ритейлера с маркетплейсом, где неожиданные изменения API со стороны маркетплейса, отсутствие проектирования «у нас» и плохо организованная коммуникация между сторонами привели к неработоспособности решения.
К счастью, сейчас всё хорошо, исправления внесены, архитектура оздоровлена, а уроки выучены.
Однако описанные предпосылки возникновения проблемы сравнительно часто встречаются в разных проектах, командах и задачах.
https://telegra.ph/sbermarket-failure-05-27
#маркетплейсы #кейсы
Описал кейс интеграции ритейлера с маркетплейсом, где неожиданные изменения API со стороны маркетплейса, отсутствие проектирования «у нас» и плохо организованная коммуникация между сторонами привели к неработоспособности решения.
К счастью, сейчас всё хорошо, исправления внесены, архитектура оздоровлена, а уроки выучены.
Однако описанные предпосылки возникновения проблемы сравнительно часто встречаются в разных проектах, командах и задачах.
https://telegra.ph/sbermarket-failure-05-27
#маркетплейсы #кейсы
Telegraph
Кейс интеграции со СберМаркетом
Введение и контекст Компания — российский дистрибьютор и ритейлер, работающий на рынке более 30 лет. Имеет развитое направление электронной торговли, в товарной матрице более 9 тыс. наименований. В разных городах России открыто более 100 фирменных магазинов.…
🔥5
YouTube
Нотация C4 и чем она полезна для проектирования Корниенко Андрей
За 20 минут рассказываю, как и зачем применять C4 на своём проекте, что отображать на каждом уровне и даю практические рекомендации, на что обращать внимание.
Оригинал диаграммы, который разбираю в видео c4-integration-example.drawio https://bit.ly/3Ay225q…
Оригинал диаграммы, который разбираю в видео c4-integration-example.drawio https://bit.ly/3Ay225q…
Нотация C4 и чем она полезна для проектирования — за 20 минут рассказываю, как и зачем применять C4 на своём проекте, что отображать на каждом уровне и даю практические рекомендации, на что обращать внимание.
Оригинал диаграммы, который разбираю в видео c4-integration-example.drawio. Учебная диаграмма — с нашего курса «Проектирование интеграции ИТ-систем».
Про (аналитить) это
#c4model
Оригинал диаграммы, который разбираю в видео c4-integration-example.drawio. Учебная диаграмма — с нашего курса «Проектирование интеграции ИТ-систем».
Про (аналитить) это
#c4model
🔥7
[1/2] Люди не понимают ООП
Меня заинтересовала статья авторства Флориана Бухбергера (Florian Buchberger) „People Don’t Understand OOP“ (русский перевод на Хабре), я кратко и вольно пересказываю её ниже. Мне представляется важным, чтобы системный аналитик разбирался в том, чем являются объекты и чем они не являются, когда анализирует предметную область и проводит онтологическое моделирование предметной области.
По-простому: рисует кубики типа «заказ», «счёт», «клиент» и соединяет их стрелочками с глаголами-описаниями взаимодействий.
Модель предметной области тесно связана с программированием: от грамотного моделирования зависит, как разработчики поймут инженерную документацию и как попытаются реализовать обеспечение бизнес-задачи в хранилищах данных и в коде.
TL;DR
Объектно-ориентированное программирование — это когда связанные состояние и поведение упаковываются в блоки (объекты). Из чего следует:
— Data Transfer Objects (DTO) — это не объекты, а записи;
— Сервисы, репозитории не хранят состояние и могут считаться функциями;
— Грамотно выделить объекты поможет опыт, есть пара советов.
Определение ООП
— Алан Кэй, американский учёный в области теории вычислительных систем, один из пионеров объектно-ориентированного программирования, в письме от 2003 года.
(1) «Объекты — это коллекции операций, разделяющих общее состояние» — Питер Вегнер
(2) «Объекты — это сущности, сочетающие в себе свойства процедур и данных, потому что они выполняют вычисления и хранят локальное состояние. Единообразное применение объектов контрастирует с использованием отдельных процедур и данных в традиционном программировании» — Марк Стефик и Дэниел Бобров
(3) «Объектно-ориентированные программы состоят из объектов. Объект включает в себя и данные, и процедуры, которые могут обрабатывать данные. Процедуры обычно называют методами или операциями» — Банда четырех
(4) «Объекты — единицы состояния, в общем случае непрозрачные снаружи. Однако объект может предоставить возможность взаимодействия со своим состоянием при помощи передачи сообщений (= „методов“)» — Тим Рентш
Классы для объектов не обязательны
Например, JavaScript и Lua используют концепцию прототипирования: использовать существующий объект как прототип для создания нового объекта.
Go и Rust используют структуры, которые похожи на классы.
Наследование
Чаще всего ассоциируется с ООП, хотя оно совсем не обязательно для ООП. Наследование позволяет объявлять новые классы на основе существующих и наследовать их атрибуты и методы. Более того, наследованием часто злоупотребляют там где лучше использовать агрегацию или композицию (примеры и разница), так что наследование вообще не рекомендуют использовать.
Полиморфизм
Позволяет изменять поведение в подтипах по сравнению с поведением базового типа. В отличие от наследования не затрагивается структура базового типа и не наследуется код; применение можно увидеть в интерфейсах (речь про абстрактные объявления сигнатур типов без реализации).
Подтипы
Собственно, реализация полиморфизма. Позволяет комбинировать разные типы, чтобы обрабатывать одинаковые сообщения — иными словами, иметь методы которые называются одинаково но делают разные вещи. Барбара Лисков предложила в 1987 году важный для ООП принцип:
#ооп
Меня заинтересовала статья авторства Флориана Бухбергера (Florian Buchberger) „People Don’t Understand OOP“ (русский перевод на Хабре), я кратко и вольно пересказываю её ниже. Мне представляется важным, чтобы системный аналитик разбирался в том, чем являются объекты и чем они не являются, когда анализирует предметную область и проводит онтологическое моделирование предметной области.
По-простому: рисует кубики типа «заказ», «счёт», «клиент» и соединяет их стрелочками с глаголами-описаниями взаимодействий.
Модель предметной области тесно связана с программированием: от грамотного моделирования зависит, как разработчики поймут инженерную документацию и как попытаются реализовать обеспечение бизнес-задачи в хранилищах данных и в коде.
TL;DR
Объектно-ориентированное программирование — это когда связанные состояние и поведение упаковываются в блоки (объекты). Из чего следует:
— Data Transfer Objects (DTO) — это не объекты, а записи;
— Сервисы, репозитории не хранят состояние и могут считаться функциями;
— Грамотно выделить объекты поможет опыт, есть пара советов.
Определение ООП
ООП означает для меня лишь обмен сообщениями, локальное сохранение, защиту и сокрытие состояния-процесса, и максимально позднее связывание всего вместе.
— Алан Кэй, американский учёный в области теории вычислительных систем, один из пионеров объектно-ориентированного программирования, в письме от 2003 года.
(1) «Объекты — это коллекции операций, разделяющих общее состояние» — Питер Вегнер
(2) «Объекты — это сущности, сочетающие в себе свойства процедур и данных, потому что они выполняют вычисления и хранят локальное состояние. Единообразное применение объектов контрастирует с использованием отдельных процедур и данных в традиционном программировании» — Марк Стефик и Дэниел Бобров
(3) «Объектно-ориентированные программы состоят из объектов. Объект включает в себя и данные, и процедуры, которые могут обрабатывать данные. Процедуры обычно называют методами или операциями» — Банда четырех
(4) «Объекты — единицы состояния, в общем случае непрозрачные снаружи. Однако объект может предоставить возможность взаимодействия со своим состоянием при помощи передачи сообщений (= „методов“)» — Тим Рентш
Классы для объектов не обязательны
Например, JavaScript и Lua используют концепцию прототипирования: использовать существующий объект как прототип для создания нового объекта.
Go и Rust используют структуры, которые похожи на классы.
Наследование
Чаще всего ассоциируется с ООП, хотя оно совсем не обязательно для ООП. Наследование позволяет объявлять новые классы на основе существующих и наследовать их атрибуты и методы. Более того, наследованием часто злоупотребляют там где лучше использовать агрегацию или композицию (примеры и разница), так что наследование вообще не рекомендуют использовать.
Полиморфизм
Позволяет изменять поведение в подтипах по сравнению с поведением базового типа. В отличие от наследования не затрагивается структура базового типа и не наследуется код; применение можно увидеть в интерфейсах (речь про абстрактные объявления сигнатур типов без реализации).
Подтипы
Собственно, реализация полиморфизма. Позволяет комбинировать разные типы, чтобы обрабатывать одинаковые сообщения — иными словами, иметь методы которые называются одинаково но делают разные вещи. Барбара Лисков предложила в 1987 году важный для ООП принцип:
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. Простыми словами — классы-наследники не должны противоречить базовому классу. Например, они не могут предоставлять интерфейс ýже базового.
#ооп
🔥2
[2/2] Люди не понимают ООП
Инкапсуляция
Под инкапсуляцией обычно понимают сразу две вещи:
(1) Передача данных вместе с поведением; собственно то, что понимается под объектом.
(2) Сокрытие внутреннего состояния от внешних наблюдателей.
Рассмотрение инкапсуляции важно, потому что в архитектуре часто используется характеристика “(Object) coupling” and “(class) cohesion” — я даже не буду пытаться перевести на русский, потому что и coupling и cohesion в лоб переводятся одним словом. Речь о том, что в хорошей архитектуре объекты слабосвязаны, а классы узкоспециализированы.
Если говорят, что объекты сильно сцеплены (high coupling) то скорее всего они должны быть одним объектом на самом деле. Говорят, что class has high cohesion когда класс имеет ясное назначение и четкие границы ответственности.
Поэтому хорошая система „has low coupling and high cohesion“. Попробуйте запомнить :)
Инкапсуляция — сокрытие внутреннего устройства от внешних наблюдателей — позволяет менять внутреннюю структуру класса не боясь убить совместимость с использующим его кодом. Мы объявляем методы, с помощью которых можно менять состояние нашего объекта; мы можем переименовывать атрибуты, дополнять и менять их местами, не разрушая совместимость. Внешний наблюдатель даже не узнает, что мы что-то поменяли и код будет работать и дальше.
Так что же такое ООП?
ООП — это когда связанные состояние и поведение упаковываются в блоки (объекты). Дополнительными характеристиками ООП могут быть: классы, прототипы, инкапсуляция, подтипирование, наследование…
Мда, непросто.
Как понять, как именно выделять объекты? Когда несколько объектов — это на самом деле один объект, а когда он вообще не объект, а запись?
Короче, опыт и практика вам в помощь (погуглите, реально часто именно это и предлагается делать: пробовать и разбираться). Согласен, мерзко дочитать аж до сюда и обнаружить, что простого ответа нет; есть парочка средних:
(1) Можно начать с рекомендации от Банды четырех:
(2) Посмотреть запись вебинара Натальи Косиновой «Как разобраться в предметной области: инструкция по применению».
Объекты, которые на деле записи или функции
И напоследок,
Если что-то названо в коде объектом и содержит только атрибуты и, возможно, геттеры-сеттеры — это на самом деле не объект, а запись. Методы для присвоения или считывания атрибутов не сильно препятствуют усилению связанности объектов; и на деле не содержат никакой логики поведения.
Классы, которые в коде называются сервисами и репозитариями и не содержат внутреннего состояния — на деле с таким же успехом могут быть заменены обычными функциями в модулях. А синглтоны — это сложный способ объявить глобальную переменную…
Так что эти инфраструктурные штуки — записи и функции — в модели предметной области, скорее всего, будут отсутствовать, и теперь понятно, почему (потому что они не объекты ).
#ооп
Инкапсуляция
Под инкапсуляцией обычно понимают сразу две вещи:
(1) Передача данных вместе с поведением; собственно то, что понимается под объектом.
(2) Сокрытие внутреннего состояния от внешних наблюдателей.
Рассмотрение инкапсуляции важно, потому что в архитектуре часто используется характеристика “(Object) coupling” and “(class) cohesion” — я даже не буду пытаться перевести на русский, потому что и coupling и cohesion в лоб переводятся одним словом. Речь о том, что в хорошей архитектуре объекты слабосвязаны, а классы узкоспециализированы.
Если говорят, что объекты сильно сцеплены (high coupling) то скорее всего они должны быть одним объектом на самом деле. Говорят, что class has high cohesion когда класс имеет ясное назначение и четкие границы ответственности.
Поэтому хорошая система „has low coupling and high cohesion“. Попробуйте запомнить :)
Инкапсуляция — сокрытие внутреннего устройства от внешних наблюдателей — позволяет менять внутреннюю структуру класса не боясь убить совместимость с использующим его кодом. Мы объявляем методы, с помощью которых можно менять состояние нашего объекта; мы можем переименовывать атрибуты, дополнять и менять их местами, не разрушая совместимость. Внешний наблюдатель даже не узнает, что мы что-то поменяли и код будет работать и дальше.
Так что же такое ООП?
ООП — это когда связанные состояние и поведение упаковываются в блоки (объекты). Дополнительными характеристиками ООП могут быть: классы, прототипы, инкапсуляция, подтипирование, наследование…
Мда, непросто.
Как понять, как именно выделять объекты? Когда несколько объектов — это на самом деле один объект, а когда он вообще не объект, а запись?
Короче, опыт и практика вам в помощь (погуглите, реально часто именно это и предлагается делать: пробовать и разбираться). Согласен, мерзко дочитать аж до сюда и обнаружить, что простого ответа нет; есть парочка средних:
(1) Можно начать с рекомендации от Банды четырех:
«…Можно написать формулировку задачи, выделить существительные и глаголы, а затем создать соответствующие классы и операции. Или можно сосредоточиться на взаимодействиях и обязанностях в системе. Или можно смоделировать реальный мир и перенести обнаруженные объекты в архитектуру. Всегда будут разногласия о том, какой подход лучше»
(2) Посмотреть запись вебинара Натальи Косиновой «Как разобраться в предметной области: инструкция по применению».
Объекты, которые на деле записи или функции
И напоследок,
Если что-то названо в коде объектом и содержит только атрибуты и, возможно, геттеры-сеттеры — это на самом деле не объект, а запись. Методы для присвоения или считывания атрибутов не сильно препятствуют усилению связанности объектов; и на деле не содержат никакой логики поведения.
Классы, которые в коде называются сервисами и репозитариями и не содержат внутреннего состояния — на деле с таким же успехом могут быть заменены обычными функциями в модулях. А синглтоны — это сложный способ объявить глобальную переменную…
Так что эти инфраструктурные штуки — записи и функции — в модели предметной области, скорее всего, будут отсутствовать, и теперь понятно, почему (
#ооп
1👍6
[1/x] Как сделать правильное логгирование
Разрозненные логи довольно сложно анализировать, поэтому первое что надо сделать — это пробрасывать в логи сквозной идентификатор.
Проще объяснить по картинке:
При возврате ответа на синхронный вызов система A (и другие, которыми вы управляете) должна вернуть значение
Применение
Тестировщик проверяет вашу систему, вызывает постманом один из эндпоинтов. Получает в ответе
Как передавать и как возвращать
Можно в теле запроса и ответа, можно в HTTP-заголовках. Обычно я проектирую исходя из привычек команды и стиля, принятого на проекте. Если стиля никакого нет — то прививаю :)
А что там за span_id такой
Этот параметр похитрее, удобен если в контуре несколько (много) систем, которые вызывают друг друга разными хитроумными способами. Тогда первая система, обрабатывающая вызов, генерирует
Проще опять по картинке понять: получается что в логе вы увидите что-то вроде «0.4.2» и сможете понять, что запись сделала третья система в цепочке, но вызвана она была далеко не первой по порядку обработки.
Подробнее об этой технике можно почитать например в документации OpenTelemetry. Если заморочиться, то можно даже визуализировать такие вызовы в дерево и осчастливить техподдержку. Им и так нелегко разгребать всё это.
#логгирование
Разрозненные логи довольно сложно анализировать, поэтому первое что надо сделать — это пробрасывать в логи сквозной идентификатор.
Проще объяснить по картинке:
trace_id — это сквозной идентификатор, который либо передаётся на вход в вашу систему, которая первая принимает вызов от других систем вне контура либо от пользователя. Если на вход не передан trace_id, то система A его генерирует и дальше сохраняет в каждой записи своего лога и передает в вызовах в другие системы (B, C, D и E).trace_id удобно сделать GUID'ом, для экономии места убрать дефисы. На входе проверять, что trace_id — это валидный гуид, и норм. Если не валидный — генерировать свой.При возврате ответа на синхронный вызов система A (и другие, которыми вы управляете) должна вернуть значение
trace_id, который использовался в ходе обработки вызова.Применение
Тестировщик проверяет вашу систему, вызывает постманом один из эндпоинтов. Получает в ответе
trace_id, и по нему ищет в GrayLog или ELK все записи, относящиеся к этой операции. Особенно это удобно, когда задействовано несколько систем и логи сохраняются в общее хранилище; если у вас нет центрального хранилища логов, то самое время его завести.Как передавать и как возвращать
Можно в теле запроса и ответа, можно в HTTP-заголовках. Обычно я проектирую исходя из привычек команды и стиля, принятого на проекте. Если стиля никакого нет — то прививаю :)
trace_id можно передавать и в сообщениях через брокер, хотя тимлиды и архитекторы иногда сопротивляются, мол, лишнее, есть и технические заголовки. Я обычно выслушиваю киваю, и делаю по-своему (если хватает полномочий).А что там за span_id такой
Этот параметр похитрее, удобен если в контуре несколько (много) систем, которые вызывают друг друга разными хитроумными способами. Тогда первая система, обрабатывающая вызов, генерирует
span_id равный нулю «0». При вызове других систем эта первая система A добавляет к span_id порядковый номер вызова, начиная с «1».Проще опять по картинке понять: получается что в логе вы увидите что-то вроде «0.4.2» и сможете понять, что запись сделала третья система в цепочке, но вызвана она была далеко не первой по порядку обработки.
Подробнее об этой технике можно почитать например в документации OpenTelemetry. Если заморочиться, то можно даже визуализировать такие вызовы в дерево и осчастливить техподдержку. Им и так нелегко разгребать всё это.
#логгирование
🔥3❤1
Провальный ИПР
Сделать нормальный план индивидуального развития можно, если четко представляешь образ результата и можешь выразить его в конкретных компетенциях, которые тебе нужны. Плюс понимаешь что в твоем багаже полезного есть прямо сейчас, что надо добавить для достижения цели.
А потом ты берешь, и делаешь то что запланировано.
На прошлой неделе один менти-системный аналитик пришел ко мне закрывать свой ИПР. На старте мы обсуждали чему он должен научиться, как он должен это сделать, каких результатов добиться.
Это было плохо. Не то чтобы он вообще ничего не сделал — нет, человек явно приложил некоторые усилия. Возможно, даже значительные, — с его точки зрения. Но их оказалось ужасно недостаточно, чтобы изменить его состояние, как системы, для выхода на новый уровень «джун-мидл».
«Кому надо — тот и носится», такой важнейший совет я услышал от одного успешного бизнесмена и запомнил на всю жизнь. Я тогда спросил, почему он при том что имеет в наличии не один огромный бизнес, лично выясняет, в каком зале он читает лекцию и привозит проектор. Он объяснил, что принял ответственность прочитать эту лекцию, и теперь халатность организаторов не должна стать причиной её срыва. Ну, я был впечатлен. Мне тогда казалось, что такие важные люди делегируют всё (нет).
Важнее всего — делание. Создай активность и получи обратную связь. Совсем идиотизмом заниматься, конечно, не нужно. Но иметь на руках ИПР и ждать, что тебя будут вести и принуждать и пинать — не стоит.
Если есть сложности с самомотивациейто сидите и ничего не делайте то возможно, вы копаете не в ту сторону; может быть стоит уточнить, чего хочется на самом деле.
Встречайтесь со своим ментором и просите обратную связь в процессе ИПР. Может быть, вам знаком этот кошмарный опыт из школы или универа, когда весь семестр не ходил к научнику, а потом в конце надо сдавать и это леденящее понимание что не сдашь? Оно регулярно пытается повториться и на проектах (у меня прям ща один заказчик пытается такое устроить. Борюсь напалмом).
#жиза
Сделать нормальный план индивидуального развития можно, если четко представляешь образ результата и можешь выразить его в конкретных компетенциях, которые тебе нужны. Плюс понимаешь что в твоем багаже полезного есть прямо сейчас, что надо добавить для достижения цели.
А потом ты берешь, и делаешь то что запланировано.
На прошлой неделе один менти-системный аналитик пришел ко мне закрывать свой ИПР. На старте мы обсуждали чему он должен научиться, как он должен это сделать, каких результатов добиться.
Это было плохо. Не то чтобы он вообще ничего не сделал — нет, человек явно приложил некоторые усилия. Возможно, даже значительные, — с его точки зрения. Но их оказалось ужасно недостаточно, чтобы изменить его состояние, как системы, для выхода на новый уровень «джун-мидл».
«Кому надо — тот и носится», такой важнейший совет я услышал от одного успешного бизнесмена и запомнил на всю жизнь. Я тогда спросил, почему он при том что имеет в наличии не один огромный бизнес, лично выясняет, в каком зале он читает лекцию и привозит проектор. Он объяснил, что принял ответственность прочитать эту лекцию, и теперь халатность организаторов не должна стать причиной её срыва. Ну, я был впечатлен. Мне тогда казалось, что такие важные люди делегируют всё (нет).
Важнее всего — делание. Создай активность и получи обратную связь. Совсем идиотизмом заниматься, конечно, не нужно. Но иметь на руках ИПР и ждать, что тебя будут вести и принуждать и пинать — не стоит.
Если есть сложности с самомотивацией
Встречайтесь со своим ментором и просите обратную связь в процессе ИПР. Может быть, вам знаком этот кошмарный опыт из школы или универа, когда весь семестр не ходил к научнику, а потом в конце надо сдавать и это леденящее понимание что не сдашь? Оно регулярно пытается повториться и на проектах (у меня прям ща один заказчик пытается такое устроить. Борюсь напалмом).
#жиза
👍11❤3🔥1
Любимое: путать теплое с мягким
Аналитикам важно различать цель и результат при проектировании ИТ-систем и написании инженерной документации. Это нужно уметь делать, чтобы принимать и успешно реализовывать правильные (достигающие целей) решения в условиях растущей неопределенности и сложности при ограниченных ресурсах.
Про (аналитить) это
#глоссарий
Аналитикам важно различать цель и результат при проектировании ИТ-систем и написании инженерной документации. Это нужно уметь делать, чтобы принимать и успешно реализовывать правильные (достигающие целей) решения в условиях растущей неопределенности и сложности при ограниченных ресурсах.
Про (аналитить) это
#глоссарий
🔥6
Оценка задач 🔮
Оценка задачи (или проекта) не гарантирует того, что специалист сделал декомпозицию и действительно продумал ход работы над ней.
Специфика оценки своей части аналитиками состоит в высокой неопределенности относительно существенной сложности системы. Мы тупо пытаемся угадать будущую сложность на основании опыта, внешних признаков, имеющихся обрывков информации.
Мне нравится конус неопределенности, который я позаимствовал у Натальи (которая подсмотрела у Сергея Нужненко). Помогает мне наглядно показать коллегам, чего стоит наша оценка.
Наблюдал ещё такой эффект: если за неточную оценку наказывать (хотя бы выговаривать) то спецы начинают перезакладываться и точность страдает. Плюс оценка в одно лицо по ощущениям довольно утомительное занятие.
В команде оцениваем коллективно (системными аналитиками) в дискуссии чтобы: (а) все смогли высказаться и указать на возможные проблемы/пути решения и (б) по одиночке не выгорали. Ну и да, пишем список примерных задач по оцениваемой фиче с детализацией, чтобы было понятно откуда оценка взялась.
Еще момент: не даю в оценку писать штуки типа «коммуникация со стейкхолдерами» 🙈 а призываю писать по существу задачи, функциональным блокам и артефактам. Напоминаю, что «встречи» и «переписка» являются частью процесса анализа и самостоятельной ценности в отрыве от задачи не представляют.
Иногда так и говорю: за письма заказчик не заплатит
Оценка задачи (или проекта) не гарантирует того, что специалист сделал декомпозицию и действительно продумал ход работы над ней.
Специфика оценки своей части аналитиками состоит в высокой неопределенности относительно существенной сложности системы. Мы тупо пытаемся угадать будущую сложность на основании опыта, внешних признаков, имеющихся обрывков информации.
Мне нравится конус неопределенности, который я позаимствовал у Натальи (которая подсмотрела у Сергея Нужненко). Помогает мне наглядно показать коллегам, чего стоит наша оценка.
Наблюдал ещё такой эффект: если за неточную оценку наказывать (хотя бы выговаривать) то спецы начинают перезакладываться и точность страдает. Плюс оценка в одно лицо по ощущениям довольно утомительное занятие.
В команде оцениваем коллективно (системными аналитиками) в дискуссии чтобы: (а) все смогли высказаться и указать на возможные проблемы/пути решения и (б) по одиночке не выгорали. Ну и да, пишем список примерных задач по оцениваемой фиче с детализацией, чтобы было понятно откуда оценка взялась.
Еще момент: не даю в оценку писать штуки типа «коммуникация со стейкхолдерами» 🙈 а призываю писать по существу задачи, функциональным блокам и артефактам. Напоминаю, что «встречи» и «переписка» являются частью процесса анализа и самостоятельной ценности в отрыве от задачи не представляют.
Иногда так и говорю: за письма заказчик не заплатит
👍4🔥1
Существенная Сложность (Essential Complexity) - сложность того, что делает система, сложность реализованных ею моделей, отражающих сложность реального мира, не зависящая от способа и деталей реализации. Сложность, порожденная решаемой проблемой, и ничто не может устранить или уменьшить её. Мы можем только управлять ею таким образом, чтобы минимизировать объем существенной сложности, рассматриваемой одновременно, до уровня, не превосходящего ограничения краткосрочной памяти человека.
— emacsway-log #глоссарий
1
Telegram
Jira Priority
Emojipack with 6 emoji for Telegram Premium subscribers.
Наглядность в коммуникациях
Рабочие сообщения в телеграме должны быть максимально информативны, чтобы экономить внимание получателей. Если вы работаете с задачами в Atlassian Jira, то рекомендую использовать кастомные эмодзи Jira Priority для указания приоритетов задач в сообщениях, например:
⬆️ Доработать фид для маркетплейсов
➡️ Добавить в мониторинг отслеживание robots.txt
Получатель может сразу оценить степень срочности указанной задачи не открывая собственно задачу.
Использование кастомных эмодзи, правда, требует платного аккаунта в телеге.
Всё это укладывается в парадигму «заботы о читателе», про которую хорошо рассказывает Максим Ильяхов в книге «Пиши, сокращай» и Ольга Лукинова в канале «Цифровой этикет».
Рабочие сообщения в телеграме должны быть максимально информативны, чтобы экономить внимание получателей. Если вы работаете с задачами в Atlassian Jira, то рекомендую использовать кастомные эмодзи Jira Priority для указания приоритетов задач в сообщениях, например:
Получатель может сразу оценить степень срочности указанной задачи не открывая собственно задачу.
Использование кастомных эмодзи, правда, требует платного аккаунта в телеге.
Всё это укладывается в парадигму «заботы о читателе», про которую хорошо рассказывает Максим Ильяхов в книге «Пиши, сокращай» и Ольга Лукинова в канале «Цифровой этикет».
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍3
[2/x] Как сделать правильное логгирование
Начать нужно с прояснения целей логгирования:
(1) Информирование о переходе систем в нештатный режим: узнать о проблеме раньше клиента;
(2) Анализ причин возникновения нештатных ситуаций: что сломалось, воспроизвести и починить;
(3) Сбор информации для оптимизации систем: анализ времени выполнения операций, найти «медленные», которые можно оптимизировать (в т.ч. на межсистемном уровне).
Иногда бОльший акцент нужно сделать в пользу защиты от вторжений, анализа уязвимостей и так далее. Всё, что связано с информационной безопасностью, лучше прояснять с профильными специалистами.
Источники информации для логов
(1) Клиентское приложение — даже веб-страницы должны вести лог, например в консоль браузера, чтобы при случае было чего отправить в техподдержку (пример — Crashlytics, Sentry)
(2) Веб-сервер — обычно имеет свои логи наподобие access.log, error.log и другие. Тупо пишет запросы и ответы на них без учёта бизнес-логики.
(3) Приложение — нужно описывать требования, какие логи хотим иметь, в каком формате, события каких типов писать и сколько хранить. Здесь учитываем бизнес-логику и архитектуру, дополнительные требования и пожелания в части анализа данных.
(4) Базы данных — обычно имеют свои логи с разной степенью детализации. Есть текстовые, есть бинарные.
(5) Сетевое оборудование — файерволлы всех типов, прокси и прочее, обычно пишут свои логи.
Что писать в лог
Типы сообщений, которые вы можете писать в лог:
(1) Получение входящих, отправка исходящих запросов;
(2) Валидация модели данных и параметров запроса;
(3) Аутентификация и авторизация — успех и ошибки отдельно;
(4) Ошибки приложения: runtime-ошибки, проблемы с сетью, долгие запросы, сообщения от используемых библиотек;
(5) Старты и остановки сущности приложения;
(6) Применение алгоритмов бизнес-логики — что пересчитано, трансформировано в данных;
(7) Исполнение потенциально опасных SQL-запросов на INSERT, UPDATE и DELETE;
(8) Создание и экспирация токенов, разрешений, изменение прав доступа, ролевые назначения;
(9) Отдельно логгировать действия пользователей с высокими административными полномочиями;
(10) Действия, потенциально опасные с юридической точки зрения: согласие пользователя на обработку персональных данных, согласование сертификатов между системами, подтверждение Terms of Use и так далее.
Возможно, стоит так же логгировать:
(11) Дерево ошибок — если позволяет стек приложения. Вся цепочка вызовов, приведшая к исключению, вместе со значениями параметров в вызванных методах, с указанием файла и строки в коде;
(12) Интенсивное использование какого-либо ресурса, превышающего пороговые значения, всё что похоже на DDOS, в том числе от корпоративных, внутренних систем;
(13) Подробный аудит изменяемых сущностей;
(14) Выявленные попытки фрода, подлога, подозрительного поведения определяемые логикой приложения;
(15) Изменение конфигурационных настроек приложения;
(16) Изменение версии приложения.
Что точно писать в лог не нужно
🔵 Пароли, токены, закрытые ключи
🔵 Database connection string
🔵 Номера банковских карт
🔵 Информацию, составляющую коммерческую тайну
🔵 Информацию, которая может быть признана незаконной для хранения — персональные данные, к примеру
Представьте, что судебные приставы изымут логи системы по решению суда и опубликуют их на сайте суда как часть материалов дела. Убрать их оттуда будет крайне проблематично. Сразу проектируйте так, чтобы подобный сценарий не стал для вас проблемой.
Как именно писать лог
Структура записи лога должна быть машиночитаемой и индексируемой. Формат данных зависит от хранилища. Одна из хорошо зарекомендовавших себя структур состоит из 4 частей — WWWW: when, where, who and what.
🔵 When — когда: дата-время, идентификаторы trace_id;
🔵 Where — где: название приложения, версия, эндпоинт, файл, модуль, компонент;
🔵 Who — кто: человек или система, адрес источника запроса, порты, идентификаторы;
🔵 What — что: тип и важность события, описание, параметры.
Для себя использую шаблон «Пример требований к логгированию», который дополняю в зависимости от специфики проекта.
#логгирование
Начать нужно с прояснения целей логгирования:
(1) Информирование о переходе систем в нештатный режим: узнать о проблеме раньше клиента;
(2) Анализ причин возникновения нештатных ситуаций: что сломалось, воспроизвести и починить;
(3) Сбор информации для оптимизации систем: анализ времени выполнения операций, найти «медленные», которые можно оптимизировать (в т.ч. на межсистемном уровне).
Иногда бОльший акцент нужно сделать в пользу защиты от вторжений, анализа уязвимостей и так далее. Всё, что связано с информационной безопасностью, лучше прояснять с профильными специалистами.
Источники информации для логов
(1) Клиентское приложение — даже веб-страницы должны вести лог, например в консоль браузера, чтобы при случае было чего отправить в техподдержку (пример — Crashlytics, Sentry)
(2) Веб-сервер — обычно имеет свои логи наподобие access.log, error.log и другие. Тупо пишет запросы и ответы на них без учёта бизнес-логики.
(3) Приложение — нужно описывать требования, какие логи хотим иметь, в каком формате, события каких типов писать и сколько хранить. Здесь учитываем бизнес-логику и архитектуру, дополнительные требования и пожелания в части анализа данных.
(4) Базы данных — обычно имеют свои логи с разной степенью детализации. Есть текстовые, есть бинарные.
(5) Сетевое оборудование — файерволлы всех типов, прокси и прочее, обычно пишут свои логи.
Что писать в лог
Типы сообщений, которые вы можете писать в лог:
(1) Получение входящих, отправка исходящих запросов;
(2) Валидация модели данных и параметров запроса;
(3) Аутентификация и авторизация — успех и ошибки отдельно;
(4) Ошибки приложения: runtime-ошибки, проблемы с сетью, долгие запросы, сообщения от используемых библиотек;
(5) Старты и остановки сущности приложения;
(6) Применение алгоритмов бизнес-логики — что пересчитано, трансформировано в данных;
(7) Исполнение потенциально опасных SQL-запросов на INSERT, UPDATE и DELETE;
(8) Создание и экспирация токенов, разрешений, изменение прав доступа, ролевые назначения;
(9) Отдельно логгировать действия пользователей с высокими административными полномочиями;
(10) Действия, потенциально опасные с юридической точки зрения: согласие пользователя на обработку персональных данных, согласование сертификатов между системами, подтверждение Terms of Use и так далее.
Возможно, стоит так же логгировать:
(11) Дерево ошибок — если позволяет стек приложения. Вся цепочка вызовов, приведшая к исключению, вместе со значениями параметров в вызванных методах, с указанием файла и строки в коде;
(12) Интенсивное использование какого-либо ресурса, превышающего пороговые значения, всё что похоже на DDOS, в том числе от корпоративных, внутренних систем;
(13) Подробный аудит изменяемых сущностей;
(14) Выявленные попытки фрода, подлога, подозрительного поведения определяемые логикой приложения;
(15) Изменение конфигурационных настроек приложения;
(16) Изменение версии приложения.
Что точно писать в лог не нужно
Представьте, что судебные приставы изымут логи системы по решению суда и опубликуют их на сайте суда как часть материалов дела. Убрать их оттуда будет крайне проблематично. Сразу проектируйте так, чтобы подобный сценарий не стал для вас проблемой.
Как именно писать лог
Структура записи лога должна быть машиночитаемой и индексируемой. Формат данных зависит от хранилища. Одна из хорошо зарекомендовавших себя структур состоит из 4 частей — WWWW: when, where, who and what.
Для себя использую шаблон «Пример требований к логгированию», который дополняю в зависимости от специфики проекта.
#логгирование
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Системный сдвиг
Сколько вы знаете способов передачи данных на клиент по инициативе сервера?
Этот пост зацепил моё внимание заявленной темой — но по прочтению у меня сложилось впечатление, что с логикой изложения что-то не то. Задал вопрос автору в каментах и продублирую его здесь.
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний😯
Юрий Куприянов ведет довольно интересный для меня канал, но иногда возникает ощущение что логика сохраняется в локальных утверждениях, но цельность всего поста будто бы чуток «троит» 😈
===
Всю статью будто бы пронизывает трудноуловимый сбой в логике повествования. Прошу прощения у автора, возможно я неверно интерпретировал некоторые утверждения в заметке.
(1) В заголовке постулируется тема по передаче данных от сервера к клиенту по инициативе сервера; к концу статьи множество понятий сваливается в кучу, включая event-driven архитектуру и логику принятия решений на уровне приложения.
Возможно я ошибаюсь, но решение о том, вокруг чего «устроены сообщения», должен принять проектировщик при проектировании системы, а не «приложение на уровне логики».
(2) Мне кажется неверно постулировать использование «оберток» GraphQL и gRPC вокруг коммуникационных протоколов по причине того, что «сложно разобраться» с этими самыми коммуникационными протоколами HTTP/* и WebSocket.
Создавались GraphQL и gRPC чтобы решить вполне конкретные проблемы:
GraphQL — язык запросов, чтобы решить проблему поставки рекурсивных данных в условиях узких каналов передачи данных;
gRPC — фреймворк, чтобы связать большое количество микросервисов написанных на разных языках в корпоративном контуре, используя преимущества протоколов SPDY, HTTP/2 и QUIC.
Выбор в пользу технологии должен делаться системно, с рассмотрением решаемых проблем и с учетом архитектуры информационных систем. Не потому, что технология сложная.
(3)
«кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими»
REST предлагался Филдингом как концепция «самоописываемого состояния гипермедиа» в условиях «анархического масштабирования сети». Основная идея состояла в том, что клиент может добраться до любого узла графа API, начав от корня и следуя ссылкам HATEOAS. В целом можно почитать комментарий Филдинга здесь или разбор диссертации Филдинга здесь.
Как архитектурный стиль REST API может стать более или менее технологическим? Да, REST вовсе не требует использования HTTP для имплементации. Но в чём именно может выражаться меньшая технологичность этого стиля?
Тот же вопрос применим и к RPC.
Буду признателен за содержательные ответы или критику.
===
Юрий обещал ответить содержательно. Записал в книжку душных напоминаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Шина vs Брокер
Вчера выступили на митапе «Шина vs Брокер» в ITFB вместе с Наташей @start_in_IT. Рассказали аналитикам, Q&A, разработчикам и руководителям проектов что это такое, чем различается и где применяется. Несмотря на то, что был вечер, удалось вовлечь ребят в проектирование выдуманной системы — пусть и в урезанном варианте, но всё же настоящее проектирование и рассуждения о том, какой способ интеграции выбрать и главное, почему именно такой.
В реальной жизни откровенно ошибочные варианты бывают редко. Обычно архитекторы и команда выбирают решение учитывая множество критериев: функциональные и нефункциональные требования, ограничения существующего ландшафта. Идёт сравнение «за» и «против» разных вариантов, взвешивание рисков, стоимости поддержки и ещё триллиона вещей. Иногда тупо решает политика; тогда инженеры пожимают плечами и готовятся разгребать последствия.
На митапе коллеги серьёзно подошли к вопросу и многие смогли неплохо аргументировать свои решения.
Мне понравилось🕶 и спасибо коллегам за приглашение!
Подумываю поучаствовать где-нибудь, а может быть даже организовать архитектурные ката:
Почитать про них можно на английском или на русском.
Вчера выступили на митапе «Шина vs Брокер» в ITFB вместе с Наташей @start_in_IT. Рассказали аналитикам, Q&A, разработчикам и руководителям проектов что это такое, чем различается и где применяется. Несмотря на то, что был вечер, удалось вовлечь ребят в проектирование выдуманной системы — пусть и в урезанном варианте, но всё же настоящее проектирование и рассуждения о том, какой способ интеграции выбрать и главное, почему именно такой.
В реальной жизни откровенно ошибочные варианты бывают редко. Обычно архитекторы и команда выбирают решение учитывая множество критериев: функциональные и нефункциональные требования, ограничения существующего ландшафта. Идёт сравнение «за» и «против» разных вариантов, взвешивание рисков, стоимости поддержки и ещё триллиона вещей. Иногда тупо решает политика; тогда инженеры пожимают плечами и готовятся разгребать последствия.
На митапе коллеги серьёзно подошли к вопросу и многие смогли неплохо аргументировать свои решения.
Мне понравилось
Подумываю поучаствовать где-нибудь, а может быть даже организовать архитектурные ката:
Это возможность в игровой форме потренировать свои архитектурные навыки на вымышленных проектах. Формат основан на Architectural katas — игре для разработчиков и архитекторов ПО.
Почитать про них можно на английском или на русском.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2