#guide
27. Интеграции. gRPC, HTTP/2, protobuf.
📍 Как вариант архитектуры RPC, протокол gRPC был создан Google для ускорения передачи данных между микросервисами и другими системами, которым необходимо взаимодействовать друг с другом.
ℹ️ В качестве формата обмена данными gRPC использует Protobuf (Protocol Buffers), в качестве транспортного протокола использует HTTP 2.0.
📌 HTTP/2 — вторая крупная версия сетевого протокола HTTP. Поддерживает двунаправленную потоковую передачу в одном TCP-соединении, позволяет группировать запросы во фреймы с возможность приоритизации, а затем объединять (мультиплексировать) и эти фреймы.
ℹ️ В общем виде формат Protobuf представляет собой закодированную в двоичный (бинарный) формат последовательность полей, состоящих из ключа и значения.
В качестве ключа выступает номер, определённый для каждого поля сообщения в proto-файле. Перед каждым полем указываются номер поля и его тип.
📌 gRPC предоставляет три типа потоковой передачи:
• На стороне сервера: клиент отправляет сообщение запроса на сервер. Сервер возвращает поток ответов клиенту. После завершения ответов сервер отправляет сообщение о состоянии (и в некоторых случаях конечные метаданные), что завершает процесс. После получения всех ответов клиент завершает свой процесс.
• На стороне клиента: клиент отправляет поток сообщений запросов на сервер. Сервер возвращает один ответ клиенту. Он (обычно) отправляет ответ после получения всех запросов от клиента и сообщения о состоянии (и в некоторых случаях конечных метаданных).
• Двунаправленный: клиент и сервер передают данные друг другу без особого порядка. Клиент это тот, кто инициирует такой вид двунаправленной потоковой передачи. Клиент также завершает соединение.
📍 В gRPC встроены функции генерации кода. При использовании REST API необходимо использовать сторонний инструмент, например Swagger, для автоматической генерации кода для вызовов gRPC API на разных языках. Аналитику остается необходимым описать формат данных в protobuf-файле, а компилятор сгенерирует клиентский и серверный код обработчика gRPC-вызова.
Генерируемый код действует как прослойка между логикой приложения и библиотекой gRPC. Этот код, используемый клиентом, называется стабом (stub, заглушка).
📖 Что почитать:
https://ru.wikipedia.org/wiki/GRPC
https://habr.com/ru/companies/tbank/articles/780024/
https://habr.com/ru/companies/otus/articles/780720/
27. Интеграции. gRPC, HTTP/2, protobuf.
В качестве ключа выступает номер, определённый для каждого поля сообщения в proto-файле. Перед каждым полем указываются номер поля и его тип.
• На стороне сервера: клиент отправляет сообщение запроса на сервер. Сервер возвращает поток ответов клиенту. После завершения ответов сервер отправляет сообщение о состоянии (и в некоторых случаях конечные метаданные), что завершает процесс. После получения всех ответов клиент завершает свой процесс.
• На стороне клиента: клиент отправляет поток сообщений запросов на сервер. Сервер возвращает один ответ клиенту. Он (обычно) отправляет ответ после получения всех запросов от клиента и сообщения о состоянии (и в некоторых случаях конечных метаданных).
• Двунаправленный: клиент и сервер передают данные друг другу без особого порядка. Клиент это тот, кто инициирует такой вид двунаправленной потоковой передачи. Клиент также завершает соединение.
Генерируемый код действует как прослойка между логикой приложения и библиотекой gRPC. Этот код, используемый клиентом, называется стабом (stub, заглушка).
https://ru.wikipedia.org/wiki/GRPC
https://habr.com/ru/companies/tbank/articles/780024/
https://habr.com/ru/companies/otus/articles/780720/
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
28. Брокеры сообщений. Kafka и RabbitMQ
📍 Apache Kafka и RabbitMQ это распределённые программные брокеры сообщений.
Их использование лежит в основе событийно-ориентированной (event-driven) архитектуры взаимодействия сервисов.
📌 Такие системы обычно состоят из трёх базовых компонентов:
• 1) сервер, обрабатывающий сообщения
• 2) производители (продюсеры), которые отправляют сообщения в некую именованную очередь, заранее сконфигурированную администратором на сервере,
• 3) потребители (консюмеры), которые считывают те же самые сообщения по мере их появления.
Продюсеры ничего не знают о консюмерах при записи данных в брокер, а консюмеры ничего не знают о продюсерах данных.
ℹ️ Существует две модели работы брокеров:
• pull-модель — потребители сами отправляют запрос раз в n секунд на сервер производителя для получения новой порции сообщений. При таком подходе потребители могут эффективно контролировать собственную нагрузку. Кроме того, pull-модель позволяет группировать сообщения в батчи, таким образом достигая лучшей пропускной способности. По такой модели, например, работает Kafka.
• push-модель — производитель самостоятельно посылает потребителю новую порцию данных. По такой модели, например, работает RabbitMQ. Она снижает задержку обработки сообщений и позволяет балансировать распределение сообщений по потребителям.
ℹ️ Существует несколько моделей доставки сообщений:
• At least once (хотя бы один раз – допускаются дубликаты сообщений): производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Для предотвращения дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные идентификаторы для сообщений и хранить список уже обработанных сообщений.
• At most once (не более чем один раз, но может не быть доставлено вообще – допускаются потери сообщений): производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно.
• Exactly once (строго только один раз – строго одно сообщение): брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
28. Брокеры сообщений. Kafka и RabbitMQ
Их использование лежит в основе событийно-ориентированной (event-driven) архитектуры взаимодействия сервисов.
• 1) сервер, обрабатывающий сообщения
• 2) производители (продюсеры), которые отправляют сообщения в некую именованную очередь, заранее сконфигурированную администратором на сервере,
• 3) потребители (консюмеры), которые считывают те же самые сообщения по мере их появления.
Продюсеры ничего не знают о консюмерах при записи данных в брокер, а консюмеры ничего не знают о продюсерах данных.
• pull-модель — потребители сами отправляют запрос раз в n секунд на сервер производителя для получения новой порции сообщений. При таком подходе потребители могут эффективно контролировать собственную нагрузку. Кроме того, pull-модель позволяет группировать сообщения в батчи, таким образом достигая лучшей пропускной способности. По такой модели, например, работает Kafka.
• push-модель — производитель самостоятельно посылает потребителю новую порцию данных. По такой модели, например, работает RabbitMQ. Она снижает задержку обработки сообщений и позволяет балансировать распределение сообщений по потребителям.
• At least once (хотя бы один раз – допускаются дубликаты сообщений): производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Для предотвращения дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные идентификаторы для сообщений и хранить список уже обработанных сообщений.
• At most once (не более чем один раз, но может не быть доставлено вообще – допускаются потери сообщений): производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно.
• Exactly once (строго только один раз – строго одно сообщение): брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
29. Kafka
📌 Кластер Kafka состоит из брокеров.
📌 Kafka хранит сообщения, которые поступают от других процессов, называемых «производителями» (producers), в формате «ключ — значение».
Ключ может быть любой: числовой, строковый, объект или вовсе пустой.
Значение тоже может быть любым — числом, строкой или объектом в своей предметной области, который можно сериализовать (JSON, Protobuf и т.д.) и хранить.
📌 В сообщении продюсер может указать время (timestamp), либо за него это сделает брокер в момент приёма сообщения.
📌 Заголовки выглядят как в HTTP-протоколе — строковые пары ключ-значение, и могут использоваться для передачи метаданных.
📌 Данные могут быть разбиты на разделы (partitions - партиции) в рамках разных тем (topics - топиков). Увеличение партиций увеличивает параллелизм чтения и записи. Партиции находятся на одном или нескольких брокерах, что позволяет кластеру масштабироваться.
Внутри партиции сообщения строго упорядочены по своим порядковым номерам (offset), а также индексируются и сохраняются вместе с временем создания.
📌 Kafka представляет механизм репликации данных в партициях между брокерами.
У каждой партиции есть настраиваемое число реплик. Одна из этих реплик называется лидером, остальные — фолловерами.
Записанные в лидера данные автоматически реплицируются фолловерами внутри кластера Kafka. Они подключаются к лидеру, читают данные и асинхронно сохраняют к себе в локальное хранилище.
Консюмеры со своей стороны также читают из лидерской партиции — это позволяет достичь консистентности при работе с данными.
Вместе с тем для сокращения сетевых задержек возможно чтение консюмерами из фолловеров, однако, данные от фолловеров будут менее актуальны, чем в лидерской партиции.
📌 У каждого из брокеров есть локальное хранилище, данные в котором могут устаревать по времени или по размеру (настроить это можно глобально или индивидуально в каждом топике).
📌 Сам топик можно представить как логический канал, через который проходят сообщения. Другие процессы, называемые «потребителями» (consumers), могут считывать сообщения из топиков.
📌 Kafka поддерживает все три формата доставки сообщений:
At most once, at least once, exactly once.
ℹ️ Минимально необходимый объем работ аналитика при проектировании интеграции заключается в:
• описании форматов данных – чаще всего это JSON;
• определение количества топиков исходя из бизнес-требований и архитектуры системы. Например, для разных типов данных (логирование, транзакции, события) могут требоваться отдельные топики. Разделение данных по топикам помогает изолировать различные потоки данных, улучшая управляемость и безопасность;
• определение параметров топика: названия топика, количества партиций (разделов), времени хранения данных или ограничения на объем хранимых данных.
• определение стратегии партиционирования: хэширование (стандартная стратегия, когда распределения между партициями используется хэш от ключа сообщения) или использование ключей партиции (используется задаваемый пользователем ключ сообщения для распределения сообщений по партициям - это помогает направлять связанные сообщения в одну партицию).
📖 Что почитать:
https://habr.com/ru/companies/piter/articles/352978/
https://habr.com/ru/companies/kuper/articles/738634/
29. Kafka
Ключ может быть любой: числовой, строковый, объект или вовсе пустой.
Значение тоже может быть любым — числом, строкой или объектом в своей предметной области, который можно сериализовать (JSON, Protobuf и т.д.) и хранить.
Внутри партиции сообщения строго упорядочены по своим порядковым номерам (offset), а также индексируются и сохраняются вместе с временем создания.
У каждой партиции есть настраиваемое число реплик. Одна из этих реплик называется лидером, остальные — фолловерами.
Записанные в лидера данные автоматически реплицируются фолловерами внутри кластера Kafka. Они подключаются к лидеру, читают данные и асинхронно сохраняют к себе в локальное хранилище.
Консюмеры со своей стороны также читают из лидерской партиции — это позволяет достичь консистентности при работе с данными.
Вместе с тем для сокращения сетевых задержек возможно чтение консюмерами из фолловеров, однако, данные от фолловеров будут менее актуальны, чем в лидерской партиции.
At most once, at least once, exactly once.
• описании форматов данных – чаще всего это JSON;
• определение количества топиков исходя из бизнес-требований и архитектуры системы. Например, для разных типов данных (логирование, транзакции, события) могут требоваться отдельные топики. Разделение данных по топикам помогает изолировать различные потоки данных, улучшая управляемость и безопасность;
• определение параметров топика: названия топика, количества партиций (разделов), времени хранения данных или ограничения на объем хранимых данных.
• определение стратегии партиционирования: хэширование (стандартная стратегия, когда распределения между партициями используется хэш от ключа сообщения) или использование ключей партиции (используется задаваемый пользователем ключ сообщения для распределения сообщений по партициям - это помогает направлять связанные сообщения в одну партицию).
https://habr.com/ru/companies/piter/articles/352978/
https://habr.com/ru/companies/kuper/articles/738634/
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
30. RabbitMQ
ℹ️ Основные термины:
• Publisher — публикует сообщения в RabbitMQ.
• Exchange —точка входа для публикации всех сообщений.
• Queue — очередь для хранения сообщений.
• Consumer — подписывается на очередь и получает от RabbitMQ сообщения.
• Источником сообщений является внешнее приложение, которое создаёт соединение (connection) по протоколу AMQP и генерирующее сообщения в брокер RabbitMQ для дальнейшей обработки.
📌 Publisher всегда пишет в exchange с routing key, совпадающим с названием очереди.
Publisher определяет delivery_mode для каждого сообщения — «признак персистентности». Это значит, что сообщение будет сохранено на диске и не исчезнет в случае перезагрузки брокера RabbitMQ.
📌 Exchange является точкой входа и маршрутизатором всех сообщений (как входящих от Publisher, так и перемещающихся от внутренних процессов в Rabbit).
Выделяют 4 типа:
Direct Exchange: Сообщение отправляется в очередь, если routing key сообщения точно совпадает с именем очереди.
Topic Exchange: Этот тип обменника позволяет маршрутизировать сообщения на основе шаблонов ключей маршрутизации.
Fanout Exchange: Сообщение отправляется во все очереди, связанных с этим обменником, независимо от ключа маршрутизации.
Headers Exchange: Маршрутизация сообщений происходит на основе заголовков (headers) сообщений, а не ключей маршрутизации.
📌 Queue (очередь), представляет из себя последовательное хранилище для необработанных сообщений. Хранение сообщений на диске (persistent) зависит от флага delivery_mode, назначаемым publisher для каждого сообщения.
Durable/Transient — признак персистентности очереди. Durable значит, что exchange сохранится после перезагрузки Rabbit. Это значение должно быть указано вместе с delivery_mode=2 (persistent).
Есть три типа очередей:
• Classic — обычная очередь, используется в большинстве случаев.
• Quorum — аналог классической очереди, но с обеспечением гарантий консистентности, достигаемый кворумом в кластере.
• Stream — новый вид очередей (начиная с версии RabbiMQ 3.9), аналог Apache Kafka.
📌 Формат сообщения:
headers — заголовки сообщения. Нужны для работы Exchange типа headers, а также для дополнительных возможностей Rabbit типа TTL.
routing key — ключ маршрутизации, может быть только один для одного сообщения;
delivery_mode — признак персистентности;
payload — полезная нагрузка, в любом сериализуемом формате.
📌 Сообщения помещаются в очереди и извлекаются по принципу FIFO (first in, first out).
ℹ️ Процесс работы RabbitMQ:
Consumer создаёт соединение (connection) по протоколу AMQP и получает сообщения из очереди.
RabbitMQ хранит сообщение до тех пор, пока принимающее приложение не подключится и не получит его из очереди. Потребитель может подтвердить получение сообщения сразу или после того, как полностью обработает его. Как только такое подтверждение получено, сообщение удаляется из очереди.
📌 RabbitMQ поддерживает два формата доставки сообщений:
At most once, at least once.
ℹ️ Минимально необходимый объем работ аналитика при проектировании интеграции заключается в:
• описании форматов данных – чаще всего это JSON;
• разработка схемы обмена сообщениями:
• определение очередей (Queues)
• описание маршрутов сообщений (routing keys)
• определение политики обмена (exchange types).
📖 Что почитать:
https://habr.com/ru/companies/slurm/articles/684412/
https://habr.com/ru/companies/slurm/articles/703060/
30. RabbitMQ
• Publisher — публикует сообщения в RabbitMQ.
• Exchange —точка входа для публикации всех сообщений.
• Queue — очередь для хранения сообщений.
• Consumer — подписывается на очередь и получает от RabbitMQ сообщения.
• Источником сообщений является внешнее приложение, которое создаёт соединение (connection) по протоколу AMQP и генерирующее сообщения в брокер RabbitMQ для дальнейшей обработки.
Publisher определяет delivery_mode для каждого сообщения — «признак персистентности». Это значит, что сообщение будет сохранено на диске и не исчезнет в случае перезагрузки брокера RabbitMQ.
Выделяют 4 типа:
Direct Exchange: Сообщение отправляется в очередь, если routing key сообщения точно совпадает с именем очереди.
Topic Exchange: Этот тип обменника позволяет маршрутизировать сообщения на основе шаблонов ключей маршрутизации.
Fanout Exchange: Сообщение отправляется во все очереди, связанных с этим обменником, независимо от ключа маршрутизации.
Headers Exchange: Маршрутизация сообщений происходит на основе заголовков (headers) сообщений, а не ключей маршрутизации.
Durable/Transient — признак персистентности очереди. Durable значит, что exchange сохранится после перезагрузки Rabbit. Это значение должно быть указано вместе с delivery_mode=2 (persistent).
Есть три типа очередей:
• Classic — обычная очередь, используется в большинстве случаев.
• Quorum — аналог классической очереди, но с обеспечением гарантий консистентности, достигаемый кворумом в кластере.
• Stream — новый вид очередей (начиная с версии RabbiMQ 3.9), аналог Apache Kafka.
headers — заголовки сообщения. Нужны для работы Exchange типа headers, а также для дополнительных возможностей Rabbit типа TTL.
routing key — ключ маршрутизации, может быть только один для одного сообщения;
delivery_mode — признак персистентности;
payload — полезная нагрузка, в любом сериализуемом формате.
Consumer создаёт соединение (connection) по протоколу AMQP и получает сообщения из очереди.
RabbitMQ хранит сообщение до тех пор, пока принимающее приложение не подключится и не получит его из очереди. Потребитель может подтвердить получение сообщения сразу или после того, как полностью обработает его. Как только такое подтверждение получено, сообщение удаляется из очереди.
At most once, at least once.
• описании форматов данных – чаще всего это JSON;
• разработка схемы обмена сообщениями:
• определение очередей (Queues)
• описание маршрутов сообщений (routing keys)
• определение политики обмена (exchange types).
https://habr.com/ru/companies/slurm/articles/684412/
https://habr.com/ru/companies/slurm/articles/703060/
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
31. WebSocket.
📍 Сокет - название программного интерфейса для обеспечения обмена данными между процессами. Для взаимодействия с помощью стека протоколов TCP/IP используются адреса и порты.
Эта пара определяет сокет («гнездо», соответствующее адресу и порту). В процессе обмена, как правило, используется два сокета — сокет отправителя и сокет получателя.
Каждый процесс может создать «слушающий» сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы.
Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т. д.
ℹ️ Websocket — это протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени после установления соединения.
📌 Для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP. Запрос отправляется на ws: или wss: URI (аналог http или https).
Сервер отвечает на запрос рукопожатием (handshake) с HTTP-кодом 101 Switching Protocols, переключается с HTTP на WebSocket и поддерживает двухстороннее соединение в реальном времени.
📌 Сервер может открывать несколько WebSocket-соединений с одним клиентом или с разными клиентами.
При этом сервер поддерживается точечная (одному), избирательная (группе) или широковещательная рассылка сообщение (всем сразу).
Для закрытия соединения клиент должен отправить запрос серверу, а он по истечению таймаута тоже должен отправить ответ на подтверждение закрытия.
🗣️ WebSocket подходит, когда нужны обновления данных в реальном времени и возможность доставлять сообщения клиенту без постоянных запросов.
📖 Что почитать:
https://ru.wikipedia.org/wiki/WebSocket
31. WebSocket.
Эта пара определяет сокет («гнездо», соответствующее адресу и порту). В процессе обмена, как правило, используется два сокета — сокет отправителя и сокет получателя.
Каждый процесс может создать «слушающий» сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы.
Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т. д.
Сервер отвечает на запрос рукопожатием (handshake) с HTTP-кодом 101 Switching Protocols, переключается с HTTP на WebSocket и поддерживает двухстороннее соединение в реальном времени.
При этом сервер поддерживается точечная (одному), избирательная (группе) или широковещательная рассылка сообщение (всем сразу).
Для закрытия соединения клиент должен отправить запрос серверу, а он по истечению таймаута тоже должен отправить ответ на подтверждение закрытия.
https://ru.wikipedia.org/wiki/WebSocket
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
32. Объектно-ориентированное программирование
📍 Всех, кто планирует заниматься системной аналитикой убедительно прошу изучить хотя бы один язык программирования и самому попробовать писать код.
Это может быть любой, сколь угодно простой пет-проект или реализация архитектурных паттернов в коде.
Он поможет вам глубже понять архитектурные паттерны, иначе взглянуть на рабочие задачи, почувствовать себя на месте разработчика, понять возможные ограничения в реализациях и оценить их сроки, да и просто получить жирный плюс в карму от команды.
ℹ️ Объектно-ориентированное программирование (ООП) — методология или стиль программирования, при котором код организуется в логически связанные объекты с четкими интерфейсами и поведением. Это помогает создавать программы, которые легко понять, изменять и масштабировать
Принципы ООП:
• 1. Инкапсуляция: скрытие реализации внутри класса.
Позволяет скрыть детали реализации и предоставить интерфейс для взаимодействия с объектом - обеспечивает безопасность и упрощает использование объекта другими частями программы
Класс Human содержит:
- приватную переменную age
- публичный метод setAge()
Переменная age скрыта от прямого доступа извне класса - предотвращает непреднамеренное изменение их значений.
Вместо этого доступ к ним осуществляется через публичные методы класса setAge() - есть контроль доступа к данным.
• 2. Наследование: создание новых классов на основе существующих.
Подклассы наследуют свойства и методы родительского класса - можно повторно использовать код и упростить разработку.
Подклассы могут расширять функциональность родительского класса, добавляя новые методы или изменяя существующие.
Рассмотрим классы Developer и SeniorDeveloper.
Класс SeniorDeveloper - подкласс Developer. Т.е. можно наследовать от него его свойства и методы.
Класс SeniorDeveloper может добавлять собственные методы, например, consult(), расширяя функциональность базового класса Developer.
• 3. Полиморфизм: способность объектов разных типов использовать общий интерфейс для выполнения различных действий.
Проявляется в том, что разные объекты могут реагировать на одну и ту же команду по-разному в зависимости от их типа.
У нас есть классы JavaDeveloper и PythonDeveloper, оба имеют метод writeCode()
Когда вызывается метод writeCode () для объекта класса JavaDeveloper, он пишет код на Java, а для объекта класса PythonDeveloper – на Python.
• 4. Абстракция: позволяет отделить концепцию от её реализации.
Уровень абстракции скрывает сложные детали реализации и предоставляет простой интерфейс для использования объекта - помогает сосредоточиться на важных аспектах объекта, игнорируя незначительные детали.
Интерфейс codeWriter абстрактный и имеет метод без реализации writeCode().
Интерфейс является абстракцией (разработчик или аналитик тоже может писать код). Объект такого класса невозможно создать.
Developer или Analyst реализуют интерфейс codeWriter и реализуют метод writeCode().
• Также есть понятие абстрактного класса - когда класс настолько абстрактен, что его нельзя использовать для создания конкретных экземпляров класса.
Но в этом случае можно наследоваться от него дочерними классами.
❗️ Как выбрать что использовать: абстрактный класс или интерфейс?
• Сильное отношение родитель-потомок должно быть смоделировано с помощью классов.
• Слабое отношение, указывающее на то, что объект обладает определенным свойством, должно быть смоделировано с помощью интерфейсов.
32. Объектно-ориентированное программирование
Это может быть любой, сколь угодно простой пет-проект или реализация архитектурных паттернов в коде.
Он поможет вам глубже понять архитектурные паттерны, иначе взглянуть на рабочие задачи, почувствовать себя на месте разработчика, понять возможные ограничения в реализациях и оценить их сроки, да и просто получить жирный плюс в карму от команды.
Принципы ООП:
• 1. Инкапсуляция: скрытие реализации внутри класса.
Позволяет скрыть детали реализации и предоставить интерфейс для взаимодействия с объектом - обеспечивает безопасность и упрощает использование объекта другими частями программы
Класс Human содержит:
- приватную переменную age
- публичный метод setAge()
Переменная age скрыта от прямого доступа извне класса - предотвращает непреднамеренное изменение их значений.
Вместо этого доступ к ним осуществляется через публичные методы класса setAge() - есть контроль доступа к данным.
• 2. Наследование: создание новых классов на основе существующих.
Подклассы наследуют свойства и методы родительского класса - можно повторно использовать код и упростить разработку.
Подклассы могут расширять функциональность родительского класса, добавляя новые методы или изменяя существующие.
Рассмотрим классы Developer и SeniorDeveloper.
Класс SeniorDeveloper - подкласс Developer. Т.е. можно наследовать от него его свойства и методы.
Класс SeniorDeveloper может добавлять собственные методы, например, consult(), расширяя функциональность базового класса Developer.
• 3. Полиморфизм: способность объектов разных типов использовать общий интерфейс для выполнения различных действий.
Проявляется в том, что разные объекты могут реагировать на одну и ту же команду по-разному в зависимости от их типа.
У нас есть классы JavaDeveloper и PythonDeveloper, оба имеют метод writeCode()
Когда вызывается метод writeCode () для объекта класса JavaDeveloper, он пишет код на Java, а для объекта класса PythonDeveloper – на Python.
• 4. Абстракция: позволяет отделить концепцию от её реализации.
Уровень абстракции скрывает сложные детали реализации и предоставляет простой интерфейс для использования объекта - помогает сосредоточиться на важных аспектах объекта, игнорируя незначительные детали.
Интерфейс codeWriter абстрактный и имеет метод без реализации writeCode().
Интерфейс является абстракцией (разработчик или аналитик тоже может писать код). Объект такого класса невозможно создать.
Developer или Analyst реализуют интерфейс codeWriter и реализуют метод writeCode().
• Также есть понятие абстрактного класса - когда класс настолько абстрактен, что его нельзя использовать для создания конкретных экземпляров класса.
Но в этом случае можно наследоваться от него дочерними классами.
• Сильное отношение родитель-потомок должно быть смоделировано с помощью классов.
• Слабое отношение, указывающее на то, что объект обладает определенным свойством, должно быть смоделировано с помощью интерфейсов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
33. Продуктовые метрики, проектный подход и Agile. Матрица ответственности и коммуникаций.
📍 Разделение всех методологий управления проектами на Agile и Waterfall — это общепринятый способ классифицировать подходы к организации процесса разработки программного обеспечения.
ℹ️ Waterfall (водопад/каскадная модель) - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
➕ Водопадная модель отличается простотой и понятностью, а также применима в условиях фиксированного бюджета и сроков.
➖ Вместе с тем ее недостатками является отсутствие гибкости к изменениям, из-за чего следуют высокие риски – возникновение ошибок на последних этапах может привести к срыву сроков или увеличению бюджета на разработку.
ℹ️ Agile — это семейство гибких методологий управления проектами.
• Суть Agile содержится в четырёх пунктах его манифеста:
• Люди и их взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с клиентами важнее условий контракта.
• Реагирование на изменения важнее следования плану.
📌 К Agile относят основные фреймворки: Scrum, Kanban, Lean, LeSS, SAFe.
➕ Основными преимуществами Agile является высокая гибкость к изменениям, скорость вывода нового функционала и снижение рисков в виду итеративной разработки и возможности получать обратную связь продукте по мере его разработки.
➖ Основными недостатками являются сложности планирования сроков и бюджета.
📍 При проектировании или изменении процессов, требуется организовать ответственность и взаимоотношения между ролями, задействованными в процессе.
ℹ️ Методика (матрица) RACI является удобным и наглядным средством, определяющим участие различных ролей в процедурах и процессах.
📌 Термин RACI является аббревиатурой:
R – Responsible (исполняет);
A – Accountable (отвечает);
C – Consult before doing (консультирует);
I – Inform after doing (информируется).
❗️ В каждой процедуре каждой роли должен быть присвоен тот или иной литер, при этом Accountable – должен быть только один, Responsible – должен быть в наличии по каждой процедуре, каждая процедура обязательно должна иметь Accountable и Responsible.
📖 Что почитать:
https://practicum.yandex.ru/blog/chto-takoe-pmbok-i-dlya-chego-on-nuzhen/
https://ru.wikipedia.org/wiki/Матрица_распределения_ответственности
https://habr.com/ru/articles/828096/
https://habr.com/ru/companies/otus/articles/710034/
33. Продуктовые метрики, проектный подход и Agile. Матрица ответственности и коммуникаций.
• Суть Agile содержится в четырёх пунктах его манифеста:
• Люди и их взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с клиентами важнее условий контракта.
• Реагирование на изменения важнее следования плану.
R – Responsible (исполняет);
A – Accountable (отвечает);
C – Consult before doing (консультирует);
I – Inform after doing (информируется).
https://practicum.yandex.ru/blog/chto-takoe-pmbok-i-dlya-chego-on-nuzhen/
https://ru.wikipedia.org/wiki/Матрица_распределения_ответственности
https://habr.com/ru/articles/828096/
https://habr.com/ru/companies/otus/articles/710034/
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
34. Scrum и Kanban
ℹ️ При Scrum продукт разрабатывается не разом, а по частям - каждая из них реализуется в рамках спринта.
Scrum Guide также чётко описывает состав команды, который необходим для разработки продукта.
У каждого участника — своя роль, каждый отвечает за свою часть работы, чтобы эффективно закрывать потребности пользователей.
📌 В Scrum-команду входят:
• Product Owner.
• Scrum Master.
• Development team.
Product Owner — человек, который отвечает за продукт в целом. Он следит за тем, как будет развиваться продукт, расставляет приоритеты, следит за сроками, коммуницирует со стейкхолдерами.
Scrum Master — человек, который отвечает за соблюдение принципов Scrum в команде, помогает поддерживать рабочий процесс.
Development team — группа людей (как правило, до 10 человек), которая занимается разработкой продукта, например: дизайнеры, системные аналитики, разработчики и инженеры по тестированию.
ℹ️ Атрибуты команды, которая работает по Scrum:
• Бэклог продукта — упорядоченный список задач, который ведет и обновляет Product Owner.
• Инкремент продукта — это законченная часть продукта, которая закрывает потребность пользователя.
• Спринт — это временной интервал (как правило, две недели), в течение которого идёт разработка функционала продукта.
• Бэклог спринта — упорядоченный список задач, которые запланированы на текущий спринт.
• Доска разработки — это визуальное отображение задач команды разработки в текущем спринте со статусами (как правило: Бэклог, В работе, Тестирование, Готово).
ℹ️ Scrum-команда регулярно участвует в нескольких активностях:
• Работа с бэклогом продукта и планирование спринта. – Необходимо определиться с целью спринта и выбрать из бэклога продукта задачи, которые нужно взять на ближайший спринт. Перед этим, необходимо оценить все задачи и отсортировать их по приоритету. Самые важные нужно брать в первую очередь.
• Дейли (daily — ежедневный) -В течение спринта команда собирается на ежедневные встречи — дейли. На этих встречах участники команды делятся результатами своей работы, рассказывают о проблемах, с которыми столкнулись.
• Груминг (groom - причесывать) он же product backlog refinement (PBR, уточнение бэклога) – в течение спринта команда собирается и обсуждает существующие или вновь возникшие задачи.
• Демонстрация (демо)- команда демонстрирует результаты своей работы пользователям или заказчикам. Так она получает обратную связь. (Обычно делается по окончании спринта, но в реальности делается перед тем, как выводить какую-либо функциональность на стадию тестирования).
• Ретроспектива (ретро) - Перед тем как начать новый спринт, команда проводит ретроспективу. Ретроспектива — это мероприятие, на котором вся команда обсуждает положительные и отрицательные моменты совместной работы во время предыдущего спринта.
ℹ️ Kanban не диктует чётких правил по составу, ролям и функциям в команде разработки.
Kanban предлагает набор инструментов и практик, которые позволяют улучшить работу команды.
• Scrum команда работает по спринтам, каждый из которых обычно длится две недели, а при Kanban работа идёт непрерывно.
• Kanban позволяет оперативно реагировать на изменения, то есть сразу брать в работу новые задачи, когда они появляются у команды разработки, а Scrum позволяет спланировать работу команды на ближайший спринт так, чтобы до его окончания в фокус внимания команды не попадали новые задачи.
📖 Что почитать:
https://scrumguides.org/scrum-guide.html
34. Scrum и Kanban
Scrum Guide также чётко описывает состав команды, который необходим для разработки продукта.
У каждого участника — своя роль, каждый отвечает за свою часть работы, чтобы эффективно закрывать потребности пользователей.
• Product Owner.
• Scrum Master.
• Development team.
Product Owner — человек, который отвечает за продукт в целом. Он следит за тем, как будет развиваться продукт, расставляет приоритеты, следит за сроками, коммуницирует со стейкхолдерами.
Scrum Master — человек, который отвечает за соблюдение принципов Scrum в команде, помогает поддерживать рабочий процесс.
Development team — группа людей (как правило, до 10 человек), которая занимается разработкой продукта, например: дизайнеры, системные аналитики, разработчики и инженеры по тестированию.
• Бэклог продукта — упорядоченный список задач, который ведет и обновляет Product Owner.
• Инкремент продукта — это законченная часть продукта, которая закрывает потребность пользователя.
• Спринт — это временной интервал (как правило, две недели), в течение которого идёт разработка функционала продукта.
• Бэклог спринта — упорядоченный список задач, которые запланированы на текущий спринт.
• Доска разработки — это визуальное отображение задач команды разработки в текущем спринте со статусами (как правило: Бэклог, В работе, Тестирование, Готово).
• Работа с бэклогом продукта и планирование спринта. – Необходимо определиться с целью спринта и выбрать из бэклога продукта задачи, которые нужно взять на ближайший спринт. Перед этим, необходимо оценить все задачи и отсортировать их по приоритету. Самые важные нужно брать в первую очередь.
• Дейли (daily — ежедневный) -В течение спринта команда собирается на ежедневные встречи — дейли. На этих встречах участники команды делятся результатами своей работы, рассказывают о проблемах, с которыми столкнулись.
• Груминг (groom - причесывать) он же product backlog refinement (PBR, уточнение бэклога) – в течение спринта команда собирается и обсуждает существующие или вновь возникшие задачи.
• Демонстрация (демо)- команда демонстрирует результаты своей работы пользователям или заказчикам. Так она получает обратную связь. (Обычно делается по окончании спринта, но в реальности делается перед тем, как выводить какую-либо функциональность на стадию тестирования).
• Ретроспектива (ретро) - Перед тем как начать новый спринт, команда проводит ретроспективу. Ретроспектива — это мероприятие, на котором вся команда обсуждает положительные и отрицательные моменты совместной работы во время предыдущего спринта.
Kanban предлагает набор инструментов и практик, которые позволяют улучшить работу команды.
• Scrum команда работает по спринтам, каждый из которых обычно длится две недели, а при Kanban работа идёт непрерывно.
• Kanban позволяет оперативно реагировать на изменения, то есть сразу брать в работу новые задачи, когда они появляются у команды разработки, а Scrum позволяет спланировать работу команды на ближайший спринт так, чтобы до его окончания в фокус внимания команды не попадали новые задачи.
https://scrumguides.org/scrum-guide.html
Please open Telegram to view this post
VIEW IN TELEGRAM
scrumguides.org
Scrum Guide | Scrum Guides
The Scrum Guide provided in HTML format on the web.
#guide
35. Продуктовые метрики
📍 Так как мы все живем в дивном новом мире, будет неплохо узнать еще и несколько терминов из продуктового менеджмента, с которым возможно придется столкнуться в своей деятельности аналитику.
ℹ️ Метрики продукта — это показатели, которые описывают эффективность бизнеса и помогают ему двигаться в нужном направлении. Метрики — это цифры, их необходимо рассчитывать и анализировать. Причём недостаточно сделать это один раз. Чтобы понять, как меняется продукт, показатели отслеживают в динамике. Рассмотрим два вида метрик: метрики вовлеченности и финансовые метрики. Существуют также метрики привлечения, но их здесь не будем касаться.
📌 Метрики вовлечённости. По этим показателям можно оценить, как аудитория пользуется продуктом и насколько она лояльна:
• LTV. Lifetime value — пожизненная ценность клиента: сколько денег принёс пользователь за всё время, что он покупает продукцию.
• ARPU. Average revenue per user — средний доход с пользователя. С помощью этой метрики можно оценить всю выручку, которую бизнес заработал с одного пользователя за определённый период.
• CR. Conversion rate — коэффициент конверсии. Это процент людей, которые совершили целевое действие. Например, забронировали отель на сайте путешествий или оформили кредит в приложении банка.
• Sessions per user. Число сессий — сколько и как часто люди заходят на сайт или в приложение.
• Average session length. Средняя длительность одного сеанса. Сколько времени пользователь тратит на взаимодействие с приложением или сайтом.
• DAU, WAU, MAU. Day, week, month active users — дневная, недельная, месячная активность аудитории. Количество уникальных пользователей за соответствующий период.
• NPS. Net promoter score — индекс потребительской лояльности. Он складывается из ответов пользователей на вопрос, готовы ли они порекомендовать продукт своим друзьям.
• CSI. Customer Satisfaction Index — индекс удовлетворённости покупателей. Показывает, насколько клиенты довольны услугами или товарами компании.
📌 Финансовые метрики показывают, сколько денег бизнес тратит на создание и продвижение продукта, а также сколько зарабатывает на продаже товаров и услуг:
• Revenue. Доход — деньги, которые бизнес получает за продажу своей продукции.
• GMV. Gross merchandise value — оборот. Показывает общую стоимость проданных товаров и услуг.
• ARPU. Average revenue per user — средняя выручка на одного пользователя: сколько денег получает компания от каждого клиента.
• EBITDA. Прибыль — разница между оборотом и расходом до вычета налогов и сборов.
35. Продуктовые метрики
• LTV. Lifetime value — пожизненная ценность клиента: сколько денег принёс пользователь за всё время, что он покупает продукцию.
• ARPU. Average revenue per user — средний доход с пользователя. С помощью этой метрики можно оценить всю выручку, которую бизнес заработал с одного пользователя за определённый период.
• CR. Conversion rate — коэффициент конверсии. Это процент людей, которые совершили целевое действие. Например, забронировали отель на сайте путешествий или оформили кредит в приложении банка.
• Sessions per user. Число сессий — сколько и как часто люди заходят на сайт или в приложение.
• Average session length. Средняя длительность одного сеанса. Сколько времени пользователь тратит на взаимодействие с приложением или сайтом.
• DAU, WAU, MAU. Day, week, month active users — дневная, недельная, месячная активность аудитории. Количество уникальных пользователей за соответствующий период.
• NPS. Net promoter score — индекс потребительской лояльности. Он складывается из ответов пользователей на вопрос, готовы ли они порекомендовать продукт своим друзьям.
• CSI. Customer Satisfaction Index — индекс удовлетворённости покупателей. Показывает, насколько клиенты довольны услугами или товарами компании.
• Revenue. Доход — деньги, которые бизнес получает за продажу своей продукции.
• GMV. Gross merchandise value — оборот. Показывает общую стоимость проданных товаров и услуг.
• ARPU. Average revenue per user — средняя выручка на одного пользователя: сколько денег получает компания от каждого клиента.
• EBITDA. Прибыль — разница между оборотом и расходом до вычета налогов и сборов.
Please open Telegram to view this post
VIEW IN TELEGRAM
#guide
36. Итоги🥇
Итак, совсем коротко, если вы работаете системным аналитиком в Agile-команде ваш рабочий процесс выглядит примерно так:
собрали требования – описали требования – согласовали с заинтересованными сторонами (стейкхолдерами) – спроектировали HLD – обсудили с командой –– спроектировали LLD – обсудили с командой – декомпозировали задачи и оценили время – отдали в разработку.
В итоге ваша постановка задачи на разработку будет содержать следующие пункты:
• Введение, цель: описание бизнес-контекста, бизнес-потребности.
• Заинтересованные стороны: перечень людей, влияющие на принятие решений, матрица ответственности (RACI).
• Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д.
• Описание решения:
способ и границы реализации (Use Case, макеты UX/UI, описание интеграций).
• Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных.
• Нефункциональные требования и ограничения решения: производительность, масштабируемость, доступность и т.д.
• Критерии приемки, по которым будет оцениваться успешное завершение работы над задачей.
❗️ 90% того, что для этого надо знать и уметь описано выше. Я постарался дать свое видение о процессах, связанных с системным анализом, применительно к реальным кейсам.
Разумеется это лишь сравнительно небольшая часть того, с чем сталкиваются на практике, но объем изложенного выше соответствует требованиям к аналитику на уровне Middle. Хотя требования сейчас ощутимо варьируются от компании к компании и, зная изложенное выше, можно легко попасть и на Senior позицию 😀, но без практических навыков на ней, конечно, будет непросто.
👀 На этой ноте, если вы не передумали идти дальше, желаю вам удачи в путешествии в увлекательный мир информационных технологий.
❗️ Вся серия постов гайда по профессии в этом канале отмечена хештегом #guide
36. Итоги
Итак, совсем коротко, если вы работаете системным аналитиком в Agile-команде ваш рабочий процесс выглядит примерно так:
собрали требования – описали требования – согласовали с заинтересованными сторонами (стейкхолдерами) – спроектировали HLD – обсудили с командой –– спроектировали LLD – обсудили с командой – декомпозировали задачи и оценили время – отдали в разработку.
В итоге ваша постановка задачи на разработку будет содержать следующие пункты:
• Введение, цель: описание бизнес-контекста, бизнес-потребности.
• Заинтересованные стороны: перечень людей, влияющие на принятие решений, матрица ответственности (RACI).
• Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д.
• Описание решения:
способ и границы реализации (Use Case, макеты UX/UI, описание интеграций).
• Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных.
• Нефункциональные требования и ограничения решения: производительность, масштабируемость, доступность и т.д.
• Критерии приемки, по которым будет оцениваться успешное завершение работы над задачей.
Разумеется это лишь сравнительно небольшая часть того, с чем сталкиваются на практике, но объем изложенного выше соответствует требованиям к аналитику на уровне Middle. Хотя требования сейчас ощутимо варьируются от компании к компании и, зная изложенное выше, можно легко попасть и на Senior позицию 😀, но без практических навыков на ней, конечно, будет непросто.
Please open Telegram to view this post
VIEW IN TELEGRAM
Топ-3 книг для системных аналитиков
1️⃣ Фундаментальный подход к программной архитектуре. М. Ричардс и Н. Форд.
🔥 На мой взгляд лучшая книга для понимания архитектурных подходов к проектированию систем. Содержит в себе емкое и точное описание всех основных архитектурных стилей, определения их компонентов, а также преимущества и недостатки каждого из них.
2️⃣ System Design. Подготовка к сложному интервью. А. Сюй
🔥 Книга позволяет чуть шире взглянуть на то, как устроены современные гиганты типа YouTube и Facebook и даёт понимание как проектируются системы подобного уровня. Содержит конкретные вопросы из реальных интервью и примеры решений задач по system design.
3️⃣ Создание микросервисов. С. Ньюмэн
🔥 Содержит современные решения по проектированию, разработке, интеграции, тестированию, развертыванию и мониторингу сервисов.
1️⃣ Фундаментальный подход к программной архитектуре. М. Ричардс и Н. Форд.
2️⃣ System Design. Подготовка к сложному интервью. А. Сюй
3️⃣ Создание микросервисов. С. Ньюмэн
Please open Telegram to view this post
VIEW IN TELEGRAM
#Хабр
Друзья!
Мне было довольно неожиданно и приятно обнаружить с утра, что нас уже целых 100 человек в сообществе!🚀
Вот так действует магия Хабра, с которого многие из вас пришли сюда, после моей публикации первой статьи из серии, посвящённой гайду по профессии системного аналитика.
А ещё это значит, что тема актуальна и интересна для сообщества!
Хочу сказать каждому спасибо за доверие❤️
В ближайшее время на Хабре выйдет продолжение цикла статей с актуализированными материалами.
На каждую из них я буду дублировать здесь ссылку.
А пока вы можете ознакомиться с материалами гайда в канале по хештегу #guide.
Если у вас появляются какие-либо вопросы - смело задавайте их в комментариях к постам, я обязательно отвечу.
Друзья!
Мне было довольно неожиданно и приятно обнаружить с утра, что нас уже целых 100 человек в сообществе!
Вот так действует магия Хабра, с которого многие из вас пришли сюда, после моей публикации первой статьи из серии, посвящённой гайду по профессии системного аналитика.
А ещё это значит, что тема актуальна и интересна для сообщества!
Хочу сказать каждому спасибо за доверие
В ближайшее время на Хабре выйдет продолжение цикла статей с актуализированными материалами.
На каждую из них я буду дублировать здесь ссылку.
А пока вы можете ознакомиться с материалами гайда в канале по хештегу #guide.
Если у вас появляются какие-либо вопросы - смело задавайте их в комментариях к постам, я обязательно отвечу.
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Системный аналитик. Краткий гайд по профессии. Часть 1. Основы взаимодействия систем
Данный текст является вводной статьей , и преимущественно ориентирован на новичков в IT-индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных принципах,...
#Хабр
Друзья!
Сегодня вышла новая часть статьи на Хабре!
Из статьи вы узнаете о типах требований, рассмотрите пример их оформления, узнаете какие существуют методы сбора требований, как проводить интервью и анкетирование, рассмотрите основные типы диаграмм (Use Case, Sequence, State, Class, ER-diagram, BPMN) и инструменты, используемые при документировании требований.
Если статья будет интересной и полезной для вас, можете проголосовать за нее на Хабре - так она выйдет в топ новостной ленты и ее смогут увидеть больше пользователей🔝
Желаю приятного чтения!
Друзья!
Сегодня вышла новая часть статьи на Хабре!
Из статьи вы узнаете о типах требований, рассмотрите пример их оформления, узнаете какие существуют методы сбора требований, как проводить интервью и анкетирование, рассмотрите основные типы диаграмм (Use Case, Sequence, State, Class, ER-diagram, BPMN) и инструменты, используемые при документировании требований.
Если статья будет интересной и полезной для вас, можете проголосовать за нее на Хабре - так она выйдет в топ новостной ленты и ее смогут увидеть больше пользователей
Желаю приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Системный аналитик. Краткий гайд по профессии. Часть 2. Сбор, анализ и документирование требований (UML, BPMN)
Данный текст является обзорной статьей и преимущественно ориентирован на новичков в IT-индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных...
Друзья!
Нас уже 200 человек в сообществе! 🚀
Завтра я планирую выпустить новую статью на Хабре, в которой расскажу об монолитной и распределенной архитектурах (SOA, MSA, EDA), расскажу, как рассчитать нагрузку и стоимость, как масштабировать микросервисы и БД в высоконагруженных системах.
😕 Но есть нюанс. Какие-то снобы ставят мне минусы в карму на Хабре, видимо за то, что я посмел поделиться своими знаниями с аудиторией.
❗️ Поэтому, если мой контент вам помог, или просто нравится, и у вас есть профиль на Хабре, я хочу попросить поставить мне «плюсик» в карму на Хабре. Для этого необходимо перейти в мой профиль и нажать «стрелочку вверх», которая будет изображена рядом с показателем кармы (не путать с рейтингом).
https://habr.com/ru/users/nick_oldman/
Это будет важно для того, чтобы статья не попадала в Recovery Mode и чаще показывалась в новостной ленте аудитории.
✅ Даже если завтра в течение дня показатель кармы не выйдет в плюс, то я все равно выпущу эту статью в Recovery Mode и выложу сюда ссылку на неё.
Благодарю за понимание❤️
Нас уже 200 человек в сообществе! 🚀
Завтра я планирую выпустить новую статью на Хабре, в которой расскажу об монолитной и распределенной архитектурах (SOA, MSA, EDA), расскажу, как рассчитать нагрузку и стоимость, как масштабировать микросервисы и БД в высоконагруженных системах.
😕 Но есть нюанс. Какие-то снобы ставят мне минусы в карму на Хабре, видимо за то, что я посмел поделиться своими знаниями с аудиторией.
https://habr.com/ru/users/nick_oldman/
Это будет важно для того, чтобы статья не попадала в Recovery Mode и чаще показывалась в новостной ленте аудитории.
✅ Даже если завтра в течение дня показатель кармы не выйдет в плюс, то я все равно выпущу эту статью в Recovery Mode и выложу сюда ссылку на неё.
Благодарю за понимание
Please open Telegram to view this post
VIEW IN TELEGRAM
#Хабр
Друзья!
Как я вчера и обещал, на Хабре вышла новая часть статьи об архитектуре приложений!
В ней вы познакомитесь с основными типами архитектуры, узнаете как оценить нагрузку и рассчитать стоимость, как масштабировать микросервисы и БД в высоконагруженных системах, познакомитесь с понятием CAP-теоремы и уровнями изоляции транзакций в БД.
Если статья будет интересной и полезной для вас, можете проголосовать за нее на Хабре - так она выйдет в топ новостной ленты и ее смогут увидеть больше пользователей🔝
Желаю приятного чтения!
Друзья!
Как я вчера и обещал, на Хабре вышла новая часть статьи об архитектуре приложений!
В ней вы познакомитесь с основными типами архитектуры, узнаете как оценить нагрузку и рассчитать стоимость, как масштабировать микросервисы и БД в высоконагруженных системах, познакомитесь с понятием CAP-теоремы и уровнями изоляции транзакций в БД.
Если статья будет интересной и полезной для вас, можете проголосовать за нее на Хабре - так она выйдет в топ новостной ленты и ее смогут увидеть больше пользователей
Желаю приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Системный аналитик. Краткий гайд по профессии. Часть 3. Архитектура приложений и их масштабирование
Из этой статьи вы узнаете об основных широко используемых типах программной архитектуры, их преимуществах и недостатках, узнаете, как выбрать архитектуру и рассчитать нагрузку при проектировании...
#Хабр
Друзья!
Сегодня вышли две новые статьи на Хабре!🚀
Статья о синхронных и асинхронных интеграциях: REST, gRPC, Kafka, RabbitMQ, WebSocket.
Статья о методологиях разработки: Waterfall и Agile (Scrum, Kanban).
На этом серия статей, посвященных основам профессии системного аналитика, закончена.
Надеюсь, было познавательно и полезно.
Задавать интересующие вас вопросы вы можете в комментариях, или мне в лс @oldschoolsysdes
Желаю приятного чтения!
Друзья!
Сегодня вышли две новые статьи на Хабре!
Статья о синхронных и асинхронных интеграциях: REST, gRPC, Kafka, RabbitMQ, WebSocket.
Статья о методологиях разработки: Waterfall и Agile (Scrum, Kanban).
На этом серия статей, посвященных основам профессии системного аналитика, закончена.
Надеюсь, было познавательно и полезно.
Задавать интересующие вас вопросы вы можете в комментариях, или мне в лс @oldschoolsysdes
Желаю приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Системный аналитик. Краткий гайд по профессии. Часть 4. Синхронные и асинхронные интеграции. REST, gRPC, Kafka, RabbitMQ
Из этой статьи вы узнаете об основных наиболее часто используемых типах интеграции приложений и распределенных систем, таких как REST, gRPC, Kafka, RabbitMQ, WebSocket. Системный аналитик....
#Хабр
Друзья, привет!
Выложил на Хабре новую статью о best practices проектирования REST API👨💻
В статье рассмотрено, как реализовать получение данных с пагинацией с помощью GET и POST методов, приложен шаблон описания методов, а также форматов данных на примере JSON-схемы и спецификации OpenAPI в YAML-формате.
По ссылкам в статье вы можете перейти в песочницу swagger, скопировать туда этот YAML и самостоятельно поисследовать реализацию.
Приятного чтения!
Друзья, привет!
Выложил на Хабре новую статью о best practices проектирования REST API
В статье рассмотрено, как реализовать получение данных с пагинацией с помощью GET и POST методов, приложен шаблон описания методов, а также форматов данных на примере JSON-схемы и спецификации OpenAPI в YAML-формате.
По ссылкам в статье вы можете перейти в песочницу swagger, скопировать туда этот YAML и самостоятельно поисследовать реализацию.
Приятного чтения!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Реализация REST API-метода с пагинацией на примере JSON-Schema и OpenAPI
Данный текст преимущественно ориентирован на начинающих системных аналитиков, а также всех, кто интересуется проектированием IT-систем. Постановка задачи Представим, что есть компания, продающая...