test dop Flashcards
(12 cards)
Виды интеграций и их описание
API: Как телефонный звонок между системами. Одна система запрашивает данные
другой и получает ответ сразу (например, проверка погоды в приложении).
Файловый обмен: Обмен данными через файлы (Excel, CSV). Например, ежедневная выгрузка заказов из интернет-магазина в бухгалтерскую систему.
Вебхуки: Автоматические уведомления. Как подписка на Telegram-канал — система присылает сообщение, когда происходит событие (например, оплата заказа).
Очереди сообщений (Kafka, RabbitMQ): Почтовый ящик. Система отправляет сообщение в очередь, другая забирает его, когда готова (например, обработка заказов в фоне).
Stateful vs Stateless
Stateless (без состояния) — система не помнит прошлых запросов. Каждый запрос самодостаточный. Пример: REST API или (как поиск в Google — вам не нужно логиниться для каждого запроса)
Stateful (с состоянием) — система помнит, что было раньше. Пример: интернет-магазин запоминает, что ты положил в корзину.
Из чего состоит HTTP-запрос
- Метод (GET, POST и др.) — что хотим сделать.
- URL — адрес ресурса. (например, /api/users).
- Заголовки (Headers) — дополнительная информация (например, тип данных, авторизация).
- Тело (Body) — содержимое запроса (чаще у POST, PUT). (например, JSON с логином и паролем)
Синхронность и асинхронность в REST
- Синхронно — клиент ждёт ответ. Пример: отправил запрос — ждёт, пока сервер ответит. Или Пример: оплата картой — показывается результат сразу.
- Асинхронно — клиент отправил запрос и пошёл дальше. Ответ может прийти позже (например, на e-mail, вебхук, очередь сообщений). Пример: загрузка видео на YouTube. Сервер говорит: «Принял, обрабатываю», а результат присылает на почту.
Kafka vs RabbitMQ: гарантии доставки
- Kafka: Сохраняет сообщения в логе. Гарантирует, что сообщение не потеряется (даже если сервер упал). Подходит для больших потоков данных.
- RabbitMQ: Подтверждает получение. Если система получила сообщение, оно удаляется из очереди. Есть риски потери при сбоях.
- Гарантии:
o At most once: Сообщение может не дойти (но точно не дублируется).
o At least once: Сообщение придет минимум один раз (может дублироваться, но точно дойдёт.)
o Exactly once: Сообщение придет ровно один раз (сложно настроить).
Какие документации составлял на проекте?
Примеры:
* BRD (бизнес-требования) — что хочет бизнес.
* SRS (системные/функциональные требования) — что должна делать система.
* API-документация — описание входов и выходов для интеграций.
* User Story — описание задачи с точки зрения пользователя.
Пример:
SRS:
Форма регистрации должна принимать e-mail, пароль, имя.
Пароль должен быть не менее 8 символов.
После регистрации отправляется письмо на e-mail.
Виды требований и примеры
Бизнес-требования — зачем вообще нужен проект.
Пример: повысить продажи через онлайн-магазин.
Пользовательские требования — что должен уметь пользователь.
Пример: пользователь может оформить заказ.
Функциональные требования — что должна делать система.
Пример: кнопка «Купить» оформляет заказ.
Нефункциональные требования — как должна работать система.
Пример: страница должна загружаться не более 3 секунд.
INVEST в User Story
Хорошая User Story соответствует критериям INVEST:
* Independent — независимая.
* Negotiable — обсуждаемая, не высечена в камне.
* Valuable — несёт пользу.
* Estimable — можно оценить объём работы.
* Small — маленькая.
* Testable — можно проверить.
Пример User Story:
Как покупатель, я хочу видеть историю заказов, чтобы отслеживать свои покупки.
Первые три нормальные формы (НФ) и денормализация
- 1НФ: нет повторяющихся колонок и ячеек с множеством значений.
Плохо: имя, товар1, товар2
Хорошо: имя, товар (в каждой строке один товар) - 2НФ: все колонки зависят от ключа таблицы.
Если таблица зависит от части ключа — надо разделить. - 3НФ: нет колонок, которые зависят от других колонок (только от ключа).
Например, если в таблице хранится город и индекс — лучше вынести индексы в отдельную.
Денормализация — сознательное объединение данных, чтобы ускорить работу (но может привести к дублированию).
Зачем нужен SQL аналитику
1) чтобы описать их в требования, которые он описывает для разработчиков. т.е. когда вы писали апи методы для бэка, можно было ещё написать sql запросы, которые относятся к тому или иному методу
2) если нужно проанализировать какие-то данные: допустим, выгрузить данные по тому, что продается больше всего, кто из клиентов заказал на бОльшую сумму и тд
- Выборка данных: SELECT * FROM users WHERE age > 25.
- Анализ метрик: Расчет конверсии, среднего чека.
- Создание отчетов: Ежедневные продажи по категориям.
- Проверка гипотез: Сравнение A/B тестов.
JOIN и UNION
- JOIN: Соединяет таблицы по условию (горизонтально). Пример: Таблица пользователей + заказы → вывод имени и суммы заказа.
- UNION: Объединяет результаты запросов (вертикально). Пример: Список клиентов из Москвы + список клиентов из Питера → общий список.
Группы кодов ответов HTTP
- 1xx: Информационные (например, 100 Continue).
- 2xx: Успешные (например, 200 OK).
- 3xx: Перенаправления (например, 301 Moved Permanently).
- 4xx: Ошибки клиента (например, 404 Not Found).
- 5xx: Ошибки сервера (например, 500 Internal Server Error).
