⚡ Когда не надо выбирать REST API для проекта ⚡

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

Вот несколько ситуаций, в которых использование REST API может оказаться неверным решением:

❌ Непрерывное Взаимодействие в Реальном Времени:
Для приложений, требующих постоянного соединения для быстрого обмена данными в реальном времени (например, онлайн-игры, чаты), WebSocket или другие протоколы реального времени могут быть более подходящими.

❌ Клиенты требуют различных наборов данных: Если клиенты (например, мобильное приложение и веб-сайт) требуют разных наборов данных, GraphQL может предоставить больше гибкости, позволяя клиентам запрашивать только те данные, которые им нужны.

❌ Бинарный Протокол: Если требуется эффективность и минимальные затраты на передачу данных, то протоколы, такие как gRPC, которые используют бинарные форматы передачи данных, могут быть более эффективными.

❌ Служебная Информация: Если ваш API должен передавать много служебной информации вместе с данными (например, метаданными или инструкциями обработки), SOAP может быть более подходящим, так как он предоставляет стандартизированный способ включения такой информации в сообщения.

❌ Обратная Совместимость: Если ваша система уже имеет существующие интеграции на основе другого протокола (например, SOAP), и переход на REST может вызвать сбои или требует значительной переработки, может быть рационально продолжить использовать текущий протокол.

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

Сегодня поделимся впечатлением одной из студенток программы «Системный аналитик: с нуля до опыта работы на проекте».

👉 Обычно мы сами связываемся и запрашиваем обратную связь, но Анна прислала отзыв по своей инициативе, и это особенно приятно для всей нашей команды GetAnalyst♥️ #студентыGetAnalyst
⬇️⬇️

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

Во-вторых, энергетика Екатерины. Я много кого слушала на YouTube, но именно она вызвала желание пойти на обучение.

Курс был для меня бесценным. Екатерина:
▪️объясняет, как нужно ставить задачи;
▪️даёт возможность ошибаться;
▪️помогает и направляет каждого ученика.
Это дает невероятную возможность двигаться вперёд🙌

Меняется самоощущение, когда знакомишься с материалами по новой теме, учишься, пусть и медленно (в моём случае).

Как преподаватель и бизнес-предприниматель, Екатерина меня сильно вдохновила! То, как она вкладывается во всё: от урока до разбора домашних заданий, обратной связи в группе, как организовывает всё до мелочей! Ещё приятно, что на встречах всегда дружественная атмосфера.

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

Я в восторге от того, что познакомилась подробнее с искусственным интеллектом. В мире сейчас это очень востребовано.

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

Было приятно, что Екатерина отвечает на сложные вопросы как в общем чате, так и в чате проверки прогресса, хотя могла и не делать этого и отвечать на них только в рамках консультации👌

Идеально организована структура обучения: отдельно чат с трекером, кто следит за прогрессом и напоминает о домашних заданиях; помощники техподдержки.

Понравилось, что у нас была небольшая группа! Это ЛУЧШЕЕ, редко такое встречаю! И сама группа была замечательная: ребята активные, умные, много работы вкладывали в наш проект и постоянно вдохновляли этим💪

После окончания курса даже стало грустно, что всё закончилость. Но это приятная грусть!»

Огромное спасибо Анне за такой развёрнутый отзыв. И это лишь его часть! Не передать словами всю благодарность за эти слова✨

Мы всей командой GetAnalyst желаем Анне реализоваться в профессии и добиваться новых крутых результатов с полученными знаниями 🚀

📃 Что делает системный аналитик: задачи и артефакты 📃

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

👉 Какие задачи выполняет системный аналитик, которые относятся к его зоне ответственности ⬇️

1️⃣ Собирает и документирует требования:
— функциональные и нефункциональные требования;
— требования к пользовательскому интерфейсу;
— требования к интеграциям.

Эти данные дают подробное понимание по задачам и ожиданиям от системы.

2️⃣ Создаёт диаграммы:
— диаграммы последовательности;
— диаграммы состояний;
— модель данных;
— и т. д.

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

4️⃣ Часто создаёт прототипы интерфейсов, чтобы продемонстрировать пользователям и команде, как будет выглядеть конечный продукт.

5️⃣ Создаёт документацию, которая помогает разработчикам, тестировщикам и другим участникам команды понять систему и её функционал.
Также аналитик описывает риски, которые могут повлиять на разработку.

👉 Артефакты — это инструменты для коммуникации с заказчиком и командой.
Документы, схемы и модели, которые создаются, когда аналитик изучает систему.

Они нужны для того, чтобы описать:
— как работает система;
— какие у неё требования;
— как можно решить возникшие задачи.

Артефакты делятся на два типа:
— внешние: предназначены для коммуникации с заказчиком и пользователями;
— внутренние: предназначены для команды разработки и помогают организовать работу внутри команды.

📎 Во внешние входит:
• Пользовательские истории (User Story);
• Сценарии использования (Use Case);
• Спецификация требований к программному обеспечению (SRS);
• Техническое задание.

📎 Во внутренние входит:
• Диаграммы BPMN, UML, ER;
• Прототипы интерфейсов (Figma, Sketch);
• Документ "Постановка задачи";
• Техническая документация.

Это общее видение задач и артефактов для системного аналитика. Они могут адаптироваться в зависимости от типа задачи и проекта.

Ставьте реакции и делитесь с коллегами! 🔥

Этап анализа требований перед их проектированием — один из самых важных и дорогостоящих во всём процессе разработки.

Если аналитик собрал требования некачественно или проектная команда интерпретировала их иначе, повышается риск спроектировать совсем не те возможности, которые запрашивал заказчик. А значит придётся снова тратить время и деньги, исправляя это недоразумение 🥲

Чтобы не играть в «сломанный телефон» с заказчиком и проектной командой, аналитик фиксирует требования в письменном виде и в удобном для всех участников формате. То есть создаёт ТЗ #hardGetAnalyst

ТЗ, Техническое задание (англ. requirements document) — документ, где описаны цель проекта, из каких частей он состоит, какие результаты ожидаются и каким способом их можно достичь.

ТЗ – это один из основных артефактов работы аналитика, а точнее – важный её результат.
Благодаря ТЗ все требования к проекту хранятся в одном месте и поддерживаются в актуальном состоянии.

Иногда техническое задание называют спецификацией требований (англ. Software Requirements Specification, SRS), но между этими документами есть отличия.
Спецификация, как и ТЗ, содержит информацию о требованиях к проекту, но:
⚡️требования детализированы до системного уровня;
⚡️структура документа более строгая;
⚡️объём документации больше.

Иностранные компании предпочитают работать именно со спецификациями, а в России больше распространены ТЗ, структура которых адаптируется под проект или компанию.
Тем не менее принято считать, что бизнес-аналитики больше работают именно с ТЗ, а системные – со спецификациями. Хотя и это не правило, а скорее некоторая закономерность.

Завтра о том, из каких частей состоит ТЗ ✔️

🗓🤖 [17.11 в 19:00 Мск] Нейросети для проектирования БД и SQL-запросов 🤖

В следующий понедельник будем разбираться на практике, как эффективно использовать нейросети для проектирования БД и выполнения SQL-запросов.

🤖 Использование ChatGPT (и другие нейросети) для проектирования БД + SQL-запросов
🗓 17 ноября [пн]
🕘 19:00 - 21:30 МСК

🔗 Подробности и запись

✅ Занятие проводится в рамках подписки на практикумы по БД и SQL. Участи платное - от 1390 руб.
✅ Запись будет доступна после занятия.

🎁 Уже сейчас доступно занятие в записи по SQL, с практикой в реальной БД через DBeaver 😎

👉 План:
1. Знакомство с AI-инструментами и базовыми командами. Внедрение в работу системного аналитика.
2. Проектирование физической модели БД - PostgreSQL с использованием команд ChatGPT.
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов.
4. Создание реальной БД и SQL-запросы в DBeaver.

👉 В результате практикума:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с базами данных.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.

По вопросам можно писать через сайт или @getanalyst 💬


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

🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐

Чаще всего ТЗ содержит следующие информационные блоки:

1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.

2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.

3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.

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

5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.

6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.

7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.

8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.

9️⃣ Стадии и этапы разработки, а также сроки их выполнения.

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

Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.


🧐 ПРО СТАНДАРТЫ ТЗ 🧐

Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:

❣️Международные (ISO, IEEE)
❣️Российские (ГОСТ 19, ГОСТ 34)
❣️Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)

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

Друзья, желаем результативной недели ✔️👌