https://news.1rj.ru/str/notsystemanalysis?boost

Ну а вдруг)

Как правильно задавать вопросы?

Частенько ко мне на консультации приходят с запросом: «А как понять, что я хорошо работаю?» Казалось бы, ответ очевиден - если проходишь испытательный срок и тебе не подсвечивают очевидных проблем, значит все прекрасно. Но отсутствие обратной связи, где аналитику прямо говорят - «ты красавчик», сильно бьет по самооценке. Вообще, компании заинтересованы в сохранении сотрудников и должны сами выстраивать процессы таким образом, чтобы новичку было максимально комфортно. Правда, как обычно, в какой момент что-то идёт не так, и ты работаешь, работаешь, работаешь, а понимания того, все ли нормально, так и нет.

Первым советом в такой ситуации будет - «не бояться спрашивать и разговаривать». Большинство рабочих вопросов решаются на месте, и чем думать: «А как бы мне узнать хорошо ли я сделал задачу или нет?», лучше просто спросить. В ИТ, а тем более аналитике, не очень любят молчаливых. Не нужно молчать о проблемах или о возможности сорвать сроки. Если рассказать о своих трудностях, то вас точно поймут и предложат помощь.

Другой страх: «Вдруг я спрошу вопрос, а он окажется глупый, все подумают что я не знаю эту технологию». Распространенная боль, причем как для джунов, так и для людей с опытом. Для себя я делю все вопросы на две группы: общие и относящиеся к конкретной компании. Общие - легко гуглятся и могут быть решены без привлечения помощи извне. Например, «Как работает постман?» или «Что такое user story?» Я бы не спрашивал такое, а искал ответ самостоятельно.

Специфические вопросы, не стыдно задавать коллегам. «Как устроен бизнес процесс?» «Как работает это сервис?» «Какова моя зона ответственности?» «Есть ли у вас шаблоны документов?» Все то, что нельзя свободно найти в интернете. Коллеги с радостью помогут вам, поделятся информацией или отправят ссылку на конфлюенс.

Касательно обратной связи и понимания «нормальности» работы, отличной практикой является one-to-one с лидом. Когда сотрудник и руководитель созваниваются раз в некоторое время и проговаривают, все ли их устраивает. Если такого процесса в компании нет, точно стоит поговорить с лидом и попросить его назначить такие встречи. Он вряд ли откажет.

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

Не бойтесь общаться, никто не уволит вас за кривой вопрос. Лучше лишний раз спросить/предупредить, чем потратить кучу времени на поиски, промолчать и не успеть в срок.

#база

Как создать хорошую документацию к API?

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

Как обычно, все субъективно, но на мой взгляд в API документе содержатся следующие разделы:

1) История изменений
2) Оглавление
3) Системная информация
4) Алгоритм работы
5) Примеры

История изменений. Здесь все просто, ключевая цель раздела - найти того, кто создавал доку или вносил в нее какие-либо изменения. Обычно делаю в виде таблице с колонками: дата изменения, описание изменений, связанная задача, автор изменений. Если в компании используется Jira/Confluense, связка задачи и доки будет отражаться сразу в обоих местах.

Оглавление. Для быстрой навигации по разделам документа. В конфе можно настроить автоматически.

Системная информация. Или «нефункциональные требования». Например, требования к аутентификации, порядок ретраев и таймаутов, тип входного и выходного объекта (если описываете адаптер, на вход может прийти XML, а на выходе JSON), название очереди. В общем указывается вся важная информация, которая не относится к алгоритму работы напрямую.

Алгоритм работы. Самое важное. По шагам расписываем, как работает тот или иной метод. Указываем откуда приходит сообщение (из очереди или из внешней системы или по триггеру и тд), прикладываем пример входящего сообщения. Далее описываем что мы делаем с этим сообщением: раскладываем в базу, преобразуем, формируем новый запрос и тд. Допустим, мы формируем новый запрос, тогда прикладываем его пример в формате curl, указываем метод HTTP и url, а также подробно описываем параметры запроса.

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

Затем описываем ответ, алгоритм тот же: прикладываем пример ответа и подробное описание параметров ответа.

Наконец, если требуется обработать ответ, то указываем, как мы его обрабатываем: записываем в поля таблицы или формируем новое сообщение или отправляем в очередь и тд.

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

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

В качестве бонуса, для технического описания API я бы не стал придумывать велосипед и просто использовать формат OpenAPI. Нашел ультимативный гайд, где подробно описано как документировать API.

Если наберем 25 реакций, скину пример своей документации из практики)

#база

Всем привет из Москвы!

@notsystemanalysis

Какой курс выбрать?

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

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

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

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

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

Цена. Тут все просто, есть бесплатные курсы, есть платные. Платные, как правило, выдают диплом на выходе. Вот только он может не котироваться. Точно знаю, что Яндекс выдает диплом государственного образца, но там и цена соответствующая. С другой стороны, бесплатные, это как правило записи прошедших встреч, и толку от них может быть не так много.

В качестве бонуса примеры хороших курсов:
https://getanalyst.ru/education
https://nextway.pro/
https://practicum.yandex.ru/systems-analyst/?from=catalog

И пример неудачного, здесь покрыты темы только бизнес анализа:
https://1.changellenge.com/business-analyst?utm_source=ip&utm_medium=noukash&utm_campaign=youtube240123#join

AI в работе системного аналитика

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

На текущем проекте документация ведется по принципу Docs as a Code. В качестве текстового описания используется AsciiDoc, для генерации диаграмм PlantUML, а для апишек OpenAPI. На выходе у аналитика получается три артефакта: пошаговое описание процесса, диаграмма классов и Swagger. Теперь представьте, что в API содержится 50 параметров и все их нужно указать в Swagger. Реально, но очень скучно и долго. Для автоматизации этого удовольствия на помощь приходит ChatGPT.

Перед написанием спецификации я всегда тестирую запросы. Примеры прикладывает либо партнер, либо приходится формировать самостоятельно. Из примера запроса можно собрать целый OpenAPI всего одной командой. «Here is Json, convert it into OpenAPI schema». И документ в формате OpenAPI готов. Также ChatGPT можно попросить добавить описание и примеры параметров, но тут нужно быть осторожнее, чтобы не допустить несуразицу. Вложенность объектов, кстати, тоже учитывается.

То же самое можно сделать из диаграммы классов PlantUML. Подаете на вход диаграмму классов, на выходе получаете API схему. Обратный процесс также возможен, на основе Swagger можно сгенерить PlantUML.

Наконец, очень советую бесплатное расширение для IDEA Codeium, аналог GitHub Copilot. Незаменимая штука в работе аналитика, при создании того же OpenAPI. Плагин удерживает контекст и оперативно предлагает дополнения для документации, ускоряя работу.

А вы пользуетесь AI в работе? Расскажите об этом в комментариях.

Жиза в глаз попала

@notsystemanalysis

Щупаем Postman

Нашел необычный промо материал от команды Postman.

Комикс рассказывает о том, для чего нужны API, и какие возможности предоставляет Postman.

Внезапно, там не только отправка запросов, а, например, встроенный гит.

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

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

Наберем 25 реакций и я расскажу как это делать)

Процесс собеседования. Практика

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

Задача на SQL. Наиболее популярное задание, проверяющее соответствующий скилл. Чаще всего аналитика просят написать SELECT с использованием JOIN из одной или нескольких таблиц, применив агрегатные функции и группировку. Пример реальной задачи: Выведи информацию о Supplier и Category по продуктам, у которых цена выше средней. Для выполнения использовать ресурс

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

Моделирование предметной области. Здесь чаще всего аналитика просят спроектировать какую-либо диаграмму, показав процесс или предметную область. Мне доставался и BPMN, и Sequence, и ER. В зависимости от уровня вакансии компания может вообще не привязываться к какой-либо нотации, а просто проверить системное мышление кандидата. Пример задачи на собеседовании в желтый банк звучит как: Спроектируй логическую модель данных для интернет-магазина по продаже книг. Или другой пример: Спроектируй Sequence диаграмму для процесса оплаты в банковском приложении.

Задача на работу с API. Здесь открывается пространство для творчества. Самая простая задача, найти ошибки в JSON или XML. Вопрос поинтереснее может звучать так: Спроектируй endpoint для интернет-магазина по продаже книг.

Обращаю внимание, что и в этом и в прошлом примерах присутствуют элементы системного дизайна. Чем больше вопросов аналитик задаст интервьюеру и чем сильнее сузится область работы, тем проще будет. Вы же понимаете, что за час нереально сделать адекватный API? Без должного уровня абстракции не обойтись.

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

#база

Лайфхаки Postman

Прошлый пост вам зашел сильно! Поэтому, как и обещал, рассказываю о работе с curl и переменными в постмане.

1) Postman позволяет очень удобно работать с curl. Допустим у нас есть запрос:

curl --location --request POST 'https://example.ru/lead-api/lead/check-phone' \
--header 'Authorization: Bearer ***' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'phone=78005553535'

В боковом меню проходим по пути File—>Import и просто вставляем имеющийся curl. Запрос добавится целиком. Вам останется только отправить его.

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

2) Postman позволяет работать с переменным. Одним из сценариев использования является сохранение токена и обращение к нему в последующих запросах, без постоянного ctrl+C, ctrl+V. Для создания переменных тыкаем «Environments», затем «+» и создаем новое окружение, в котором будут храниться наши переменные. Наконец, внутри окружения задаем переменную.

Теперь в запросе переходим во вкладку «Tests» (не забываем предварительно изменить окружение на только что созданное) и пишем две строчки:
var jsonData=JSON.parse(responseBody) – парсим ответ
postman.setEnvironmentVariable("access_token", jsonData.access_token) – записываем параметр «access_token» в одноименную переменную.

Во всех последующих запросах обращаемся к переменной, на время действия токена она будет валидна.

В комментариях предлагаю делиться своими фишками, упрощающими работу с Postman.

P.S. В тему работы с API, недавно выходила статья о документации, заценить можно здесь.

Всем продуктивной недели!

@notsystemanalysis

Процесс собеседования. Подходы к ведению интервью

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

«Стандартное» интервью. Интервью, каким вы себе его представляете. Часик-полтора, плотно наполненные теорией разного сорта. Топ-100 вопросов на позицию системного аналитика. Именно то, что мы с вами так тщательно разбирали последнее время. Да, это скучный подход, но все еще наиболее распространенный на рынке. Молодые интервьюеры начинают именно с него, и нельзя их винить в том, что они неправы. Выделение ключевых тем для системного аналитика и подготовка вопросов по ним, помогают сформировать структуру в голове. Другой разговор, что после десятка повторений, вопросы и ответы считываются на автомате и не приносят удовольствия. В этот момент мозг генерирует идеи, и тогда рождается второй подход.

Интервью, после которого хочется жить. Когда устал спрашивать однотипные вопросы и хочется радовать себя и кандидатов. В таком случае стоит включить воображение. А что если спрашивать аналитика исключительно по его опыту? Затронуть все интересующие темы, через вопросы а-ля: «А как вы писали документацию/Как валидировали требования/Почему именно такие способы….» Но тут и кандидат должен рассказать о прошлом опыте так, чтобы была возможность задать вопросы. Или другой пример – построить интервью через практический кейс. Не спрашивать «какие техники сбора требований знаешь», а «представь у тебя есть целевая группа, как будешь собирать требования». Я проводил такие интервью, когда мы начинали со сбора требований в БА блоке и заканчивали моделированием таблиц базы данных в СА. По итогу, кандидат и я были в восторге он проведенного времени.

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

#база

Как пройти собеседование на позицию системного аналитика?

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

Введение. Что из себя представляет интервью?
Самопрезентация
Бизнес анализ
Системный анализ
Что спросить после технического интервью?
Что еще важно знать, чтобы быть эффективнее?
Практическая секция
Рекомендации для интервьюеров

Сохраняйте, чтобы не потерять!

Легкой недели!

@notsystemanalysis

Паттерны реализации микросервисной архитектуры

Один из популярных вопросов на собеседовании уровня Senior. Паттернов много, и чем больше кандидат сможет назвать и объяснить, тем больше очков в копилку получит. Сегодня разбираем некоторые из них.

Паттерн декомпозиции на микросервисы:
- Декомпозиция по бизнес возможностям - паттерн предполагает определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них
- Декомпозиция по поддоменам (DDD) - паттерн основан на концепции DDD

Паттерн рефакторинга для перехода на микросервисы
- Душитель (Strangler) - паттерн предполагает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы.
- Слой защиты от повреждений (Anti-corruption layer) - паттерн предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба.

Паттерн управления данными в микросервисах
- Saga - паттерн предназначен для управления распределенными транзакциями
- CQRS - паттерн предлагает отделить изменение данных (Command) от чтения данных (Query)
- API композиция – паттерн предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти
- Event Sourcing - паттерн, предполагает сохранение не объектов, а их состояний
- База данных на микросервис

Паттерн взаимодействия между сервисами
- Обмен сообщениями
- Удаленный вызов процедур

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

Паттерн мониторинга состояния микросервисов
- Логи
- Метрики
- Журналирование
- Трассировка
- Отслеживание исключений
- Проверка работоспособности API

Паттерн построения пользовательского интерфейса
- На сервере
- На клиенте

Паттерн развертывания микросервисов
- Один сервис на хост
- Множество сервисов на хост

А с какими паттернами вам приходилось сталкиваться в работе?

P.S. В комментариях найдете графическую схему описанных паттернов

У меня специфический опыт. Как сменить работу?

Мы с вами много говорим о системном анализе, совершенно забывая, что помимо распространенных решений, есть узкие, вендорные. Существуют аналитики 1С, консультанты SAP, специалисты по SalesForce и другим «коробочным» решениям. Сразу скажу, я ничего не имею против вендоров, если вам нравится быть экспертом в узкой нише, это прекрасно. Тем более я сам начинал с SAP. А что же делать, если не нравится и хочется уйти в «обычное ИТ»? Когда вместо транзакций и транспортов хочется интеграций? Давайте разбираться.

Стоит оговориться, что чем дольше вы занимаетесь вендорным решением, тем больше времени крадете у самого себя. Задачи и рабочие процессы «коробки» сильно отличаются от современной разработки. Условный SAP, это всегда доработка существующего решения под нужды заказчика. Чаще всего, самые простые настройки выполняются прямо из интерфейса программы и требуют знаний конкретного софта. Мне и моим знакомым было крайне тяжело уходить с вендорного решения, потому что знания SAP (или софта любого другого вендора) никак не помогут при прохождении собеседований. Если только вы не ищите соответствующую вакансию. Как первая работа без опыта, для понимания ИТ – супер, но не больше чем на полгода-год.

Другая сторона, вы уже проработали 5-10 лет под крылом вендора, что же делать? Активно учить технологии, требуемые на собеседовании и пытаться сопоставить их с ранее решенными задачами. Летом, мы занимались с Максимом, который проработал в SAP более 15 лет. Мы разобрали его достижения, обсудили реальные боевые задачи и оказалось, что у него есть реальный опыт интеграций, работы с брокерами и т.д., только в SAP это работает и называется немного иначе. Вместе мы структурировали информацию, и научились правильно ее подавать. Поэтому выход есть.

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

А как вы относитесь к работе с вендорными решениями? Был ли такой опыт?

Работа на удаленке be like:

@notsystemanalysis

Топ-50 вопросов на позицию «Бизнес аналитика»

Наткнулся на полезный ресурс, где собраны различные вопросы по направлениям. В числе прочих фигурирует бизнес анализ. Прикладываю их ниже. От себя добавлю, что это исключительно бизнесовые вопросы. Все, что касается работы системного аналитика (архитектура, интеграции, аутентификация и тд) здесь не затрагивается.

В списке собраны вопросы как по софтам, так и по хардам

1. Какие техники выявления требований бы использовал для решения проблемы
2. Расскажи о своем опыте
3. Расскажи о себе
4. Как считаешь, при найме БА компании важны больше soft skills или hard skills
5. Что нравится больше всего в бизнес-анализе
6. Чем занимается бизнес-аналитик в продуктовой команде
7. Какой главный принцип проведения брейншторма
8. Чем отличается Product Owner от бизнес-аналитика
9. Твой совет для улучшения уровня взаимодействия разработчиков и бизнес-аналитика
10. Что такое сторипоинты (Story Points)
11. Какие методы оценки задач есть кроме Story Points
12. В чем отличие Waterfall от Agile
13. Какие минусы есть у Agile
14. Какие минусы есть у Scrum
15. Что думаешь об использовании опросников
16. Как бы написал User Story, приведи пример
17. Что такое требования
18. Какие виды требований знаешь
19. Что такое нефункциональные требования (НФТ)
20. Какие существуют методы сбора требований
21. Как валидируешь и верифицируешь требования
22. В чем разница между валидацией и верификацией требований
23. Что такое use case
24. Что такое варианты использования
25. Для чего нужна приоритезация
26. Какие методы приоритезации существуют
27. Что такое change management
28. Что самое важное в change management
29. Что такое User Story
30. Что такое критерии приёмки (acceptance criteria)
31. Что такое User Story Mapping
32. Что такое декомпозиция User Story
33. Как работает техника оценки user story - invest
34. Пришла новая задача (проблема), как будешь её решать
35. Как обеспечить прозрачную коммуникацию с клиентами
36. Что делать, если заказчик не доволен реализацией решения
37. Как определить самую неприоритетную задачу в текущем спринте
38. Как определить самую не приоритетную задачу в текущем спринте
39. Что будешь делать, если спринт начинается через 3 дня, а у твоей команды пустой бэклог
40. Что будешь делать, если team-lead говорит о невозможности реализации фичи
41. В какой момент возникает ответственность бизнес-аналитика
42. Как связана работа бизнес-аналитика с конечными пользователями (не с заказчиками)
43. Сколько проектов одновременно может вести аналитик
44. В каком виде будешь представлять заказчику промежуточные результаты
45. Что нужно делать, чтобы исключить непредусмотренные corner cases (корнер кейсы)
46. Какой жизненный цикл (SDLC) у продукта
47. Что из себя представляет документ SRS (Software requirements specification)
48. Какие разделы есть в SRS
49. Какую документацию создавал
50. Для чего нужно прототипирование интерфейсов
51. Какие инструменты используются для прототипирования интерфейсов
52. Что такое UML
53. Что такое BPMN-нотация
54. В каких ситуациях идти со списком вопросов на встречу не эффективно

Какие из них встречались вам?

Популярные стили архитектуры API

Сегодня говорим о подходах к реализации API. Очевидно, что большинство специалистов знакомы с REST и SOAP, но есть и другие технологии. Привожу некоторые из них, о каждой можно почитать подробнее по приложенным ссылкам. Графический материал, как обычно, в комментариях.

1. gRPC: Высокопроизводительный, не зависящий от языка фреймворк удаленного вызова процедур (RPC) для эффективного взаимодействия между распределенными системами, часто используемый в архитектурах микросервисов.

2. SOAP: Протокол для обмена структурированной информацией при реализации веб-сервисов, известный своими строгими стандартами и форматом сообщений на основе XML.

3. GraphQL: Язык запросов и среда выполнения для API, позволяющая клиентам запрашивать только те данные, которые им необходимы, что уменьшает избыточную и недостаточную выборку данных.

4. Webhook: Механизм взаимодействия в реальном времени, при котором приложение отправляет HTTP POST-запросы на заранее определенный URL-адрес для уведомления и запуска действий в другой системе.

5. REST: Representational State Transfer - архитектурный стиль проектирования сетевых приложений, использующий стандартные методы HTTP (GET, POST, PUT, DELETE) для манипулирования ресурсами.

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

Отдыхаем последний выходной, заряжаемся на продуктивную неделю)

@notsystemanalysis