Вебхуки и чем они отличаются от API

#интеграции #api

Тем, кто скоро на собес https://tproger.ru/articles/problems/

#собеседования

Бесплатный курс на Stepik Постановка задачи на разработку ПО при поддержке ВК

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

#курсы

4 шага как «раскопать» систему

1️⃣ Собери всё, что есть
В идеале документация может должна содержать:
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции


2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний

3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.

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

Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.

Оригинал

#требования

Чек-лист хороших требований

✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.

✅ Однозначность. Требования должны трактоваться всеми одинаково.
Отчет должен загружаться быстро. Отчет за год должен загружаться не более секунды.

✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.

✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?

✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить

✅ Атомарность. Не может быть разбито на ряд более детальных требований

Подробнее – см. свойства качественных требований

#требования

Чётко и ясно излагать мысли — один из главных навыков системного аналитика. И этот навык можно прокачать. А помочь в этом может книга от создателей сервиса glvrd.ru «Пиши, сокращай» М. Ильяхова и Л. Сарычевой

Открытый курс по документированию API

Позволяет узнать:

1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger

#интеграции #api

Как выбрать технологию для интеграции, реализовать и не сойти с ума — доклад с Analyst Days 15
Анастасии Воробьевой, интеграционного аналитика из Райфа

#интеграции #api #архитектура

🔥Книга «Создание микросервисов, 2-е издание» за авторством Ньюмена Сэма.

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

Вы познакомитесь с современными решениями для моделирования, интеграции, тестирования, развертывания и мониторинга собственных автономных сервисов

#архитектура

Graphana vs Kibana — в чём разница?

Кратко: Kibana — анализ логов и запросов, Graphana — визуализация и мониторинг нагрузки.

Подробнее. Оба инструмента с открытым исходным кодом, используются для анализа больших объёмов данных от разных систем. Хотя системы имеют созвучное название, они, как правило, используются в разных кейсах.

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

Какие задачи решает Graphana:
1️⃣ Расчёт нефункциональных требований (RPS, response time) для микросервисов
2️⃣ Мониторинг состояния и ресурсов серверов и приложений. Graphana позволяет отображать и анализировать различные метрики, связанные с работой серверов и приложений, такие как загрузка CPU, использование памяти, дисковое пространство
3️⃣ Визуализация данных из разных источников. Graphana поддерживает множество баз данных и API, которые могут быть использованы для получения и отображения данных в разных форматах

Kibana — система для поиска, анализа и визуализации данных, хранящихся в Elasticsearch. Собственно, это буква K в знаменитой ELK. Kibana позволяет использовать огромное число фильтров и поддерживает сложный поисковые (KQL) запросы для анализа логов и событий.

Какие задачи решает Kibana
1️⃣ Анализ логов запросов по определённому методу API. Kibana позволяет извлекать и анализировать данные из логов, хранящихся в Elasticsearch. Например, можно построить график распределения запросов по методам API, фильтровать по статусу ответа, времени выполнения, IP-адресу и другим параметрам
2️⃣ Визуализация данных из разных источников различными способами, используя диаграммы, таблицы, географические карты и другие типы визуализаций.

📎 Материалы
1. Руководство пользователя Kibana (ENG, RUS)
2. Видео по Кибане
3. Официальная документация Graphana
4.Обзорная статья о Graphana

#инструменты

🚫Типовые ошибки младшего системного аналитика

Всем привет! Сегодня мы рассмотрим, какие ошибки совершает джун-аналитик Вася в процессе своей работы.

1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka”

2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами

3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.

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

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

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

7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…

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

P.S. Вася, прости

#развитие