Профессия:
Валидация поля: определение и практика
Валидация поля — это процесс проверки корректности и соответствия введённых данных установленным правилам и требованиям. Это критическая часть обеспечения качества данных в приложении.
Суть валидации
Определение: Валидация поля — проверка того, что данные, введённые пользователем или полученные из системы, соответствуют определённым критериям (тип, формат, диапазон значений, и т.д.).
Основные цели:
Типы валидации
1. Валидация на уровне клиента (Frontend)
Где происходит:
Примеры:
Вторая нормальная форма (2NF)
2NF требует две вещи:
1. Таблица должна быть в 1NF
2. Все non-key атрибуты полностью зависят от primary key
Значит: атрибут должен зависеть от ЦЕЛОГО первичного ключа, а не от его части.
Пример нарушения
Представь таблицу StudentCourse с составным ключом (student_id, course_id):
student_id | course_id | grade | student_name | instructor
S1 | C1 | A | John | Prof. Smith
S1 | C2 | B | John | Prof. Jones
S2 | C1 | C | Jane | Prof. Smith
Проблема:
Исправление
Разбить на три таблицы:
Student: (student_id, student_name) Course: (course_id, instructor) Enrollment: (student_id, course_id, grade)
Особенности очередей сообщений (Message Queues)
Очереди сообщений — это асинхронный механизм для передачи данных между компонентами распределенной системы. Они являются ключевым паттерном в микросервисной архитектуре и обеспечивают слабую связанность (loose coupling) между сервисами.
Основные характеристики
Асинхронность
Надежность и гарантии доставки
Описание задач для Backend разработчиков
Описание требований для Backend — это критически важный процесс, определяющий качество и скорость разработки серверной части. System Analyst должен предоставить полную, точную и однозначную спецификацию.
1. API Specification (OpenAPI/Swagger)
Это самый важный документ для Backend разработчика. OpenAPI (Swagger) стандарт позволяет описать API полностью.
Структура спецификации:
openapi: 3.0.0
info:
title: Order Management API
version: 1.0.0
description: API для управления заказами
servers:
- url: https://api.example.com/v1
description: Production
- url: https://api-staging.example.com/v1
description: Staging
Что такое бизнес-требование?
Бизнес-требование — это описание того, что должна делать система или продукт с точки зрения бизнеса, а не технологии. Это требование фокусируется на целях, ценности и результатах, которые должны быть достигнуты для организации, клиентов или пользователей.
Характеристики бизнес-требований
Ориентация на результат
Примеры бизнес-требований
Отличие от функциональных требований
Бизнес-требование
Примеры бизнес-требований
Бизнес-требование — это описание того, что нужно компании для решения её проблемы, без описания как это реализовать технически. Это мост между бизнес-целями и техническими спецификациями.
Пример 1: E-commerce платформа (Увеличение конверсии)
Покупатели часто покидают корзину на этапе оформления заказа. Аналитика показывает, что 45% пользователей уходят после просмотра итоговой стоимости.
BR-001: Упрощение процесса оформления заказа
Описание: Система должна позволить покупателям оформить заказ быстрее, чтобы увеличить коэффициент конверсии с 18% до 25% в течение Q2 текущего года.
Обоснование:
Критерии успеха:
Мой Текущий Проект: PrepBro - Платформа для Подготовки к Интервью
Я работаю над платформой PrepBro, которая помогает соискателям готовиться к собеседованиям путем практикования с AI-ассистентом, задающим вопросы и оценивающим ответы.
Описание Проекта
Цель: Создать доступную платформу для подготовки к интервью в различные специальности (System Analyst, Backend Developer, QA, Frontend Developer и т.д.)
Основная функция: Пользователь выбирает профессию, система предлагает вопросы интервью на основе профиля, пользователь дает ответы, AI оценивает качество ответа.
Архитектура Проекта
Backend:
Frontend:
output: exportUser Story и Use Case: Сравнение и Применение
User Story и Use Case — два мощных инструмента для описания функциональности системы, но они служат разным целям и применяются в различных контекстах. Оба формата неотъемлемы для системного аналитика, но понимание их различий критично для правильного выбора инструмента.
User Story
Определение: User Story — это краткое описание функциональности с точки зрения конечного пользователя, сформулированное в простой, доступной форме.
Формат:
Как [тип пользователя]
Я хочу [действие]
Чтобы [получить выгоду/достичь цель]
Характеристики:
Пример: Как покупатель интернет-магазина, я хочу фильтровать товары по цене, чтобы найти доступные мне товары быстрее.
Мой опыт получения Use Case от бизнес-аналитика
Да, я много раз получал Use Case (сценарии использования) от бизнес-аналитика. Это важный артефакт в цепочке: Business Analyst -> System Analyst -> Developer. Поделюсь как я это рассматривал.
Что такое Use Case
Use Case (вариант использования) — это описание взаимодействия между пользователем и системой для достижения конкретной цели.
Пример:
UseCase: "Customer Makes a Purchase"
Actor: Customer
Preconditions: Customer is logged in
MainFlow:
1. Customer browses products
2. Customer adds item to cart
3. Customer proceeds to checkout
4. System displays order summary
5. Customer enters shipping address
6. Customer selects payment method
7. Customer confirms payment
8. System processes payment
9. System displays confirmation
Postconditions: Order is created in system
Как бизнес-аналитик представляет Use Case
Обычно Business Analyst создает документ вроде этого:
Пример: UC-001 User Registration
Ранжирующие оконные функции SQL
Оконные функции — это мощный инструмент SQL для работы с наборами данных. Рассмотрю все ранжирующие функции с примерами.
Основное понятие: Окно (Window)
Синтаксис:
FUNCTION() OVER (PARTITION BY column ORDER BY column)
└─────────────────────────────────────────┘
ОКНО
Как это работает:
Рядовые функции (GROUP BY):
До: SELECT department, COUNT(*) FROM employees GROUP BY department
Результат: department | count
Sales | 50
IT | 30
Оконные функции (OVER):
До: SELECT employee_id, department, salary, ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC)
Результат: employee_id | department | salary | row_number
1001 | Sales | 50000 | 1
1002 | Sales | 45000 | 2
1003 | IT | 60000 | 1
1004 | IT | 55000 | 2
Функция 1: ROW_NUMBER()
Как работает INNER JOIN
INNER JOIN — это один из наиболее часто используемых типов соединений в SQL, который объединяет две таблицы на основе условия и возвращает только совпадающие строки.
Базовая концепция
INNER JOIN возвращает строки, которые имеют совпадающие значения в обеих таблицах. Если значение есть только в одной таблице — оно не включится в результат.
Визуально это можно представить как пересечение двух множеств (Venn диаграмма):
Таблица A INNER JOIN Таблица B
1 2 3 пересечение 2 3 4
| |__________________________| |
|_____| |_____________|___
Результат: 2 3 (только совпадающие)
Синтаксис
SELECT columns
FROM table1
INNER JOIN table2
ON table1.column = table2.column
WHERE conditions;
Оба варианта эквивалентны:
-- Вариант 1: явный INNER JOIN
SELECT u.name, o.order_id
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
Реляционные vs Нереляционные базы данных
Это принципиально разные подходы к хранению и управлению данными. Выбор между ними зависит от характера данных, масштаба и требований к производительности.
Реляционные БД (RDBMS)
Примеры: PostgreSQL, MySQL, Oracle, SQL Server, MariaDB
1. Структурированные данные Данные организованы в таблицы с заранее определённой схемой (columns, types).
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE,
created_at TIMESTAMP,
role_id INT FOREIGN KEY
);
2. ACID гарантии
Виды требований в разработке систем
Требования — это спецификация того, что должна делать система. В практике system analyst используется несколько классификаций требований, каждая решает свою задачу.
По функциональности
Функциональные требования (Functional Requirements)
Мой опыт системной аналитики
За последние 10+ лет я работал на различных позициях в IT, и системная аналитика стала моей основной специализацией в последние 5 лет. Это дало мне комплексное понимание разработки от требований до production.
Основной опыт
Период: 2019-2024 (5 лет)
Период: 2014-2019 (5 лет)
Ключевые компетенции
Методы анализа и разработки систем
В контексте системного анализа существует множество методов, которые используются для изучения, проектирования и оптимизации сложных систем. Рассмотрю основные категории методов, применяемые в профессиональной практике.
Методы анализа требований
Интервьюирование — прямое общение со стейкхолдерами для выявления потребностей Анкетирование — массовый сбор информации через опросы Наблюдение — изучение текущих процессов "в поле" Анализ документации — изучение существующих регламентов и отчетов
Методы проектирования
Waterfall (водопад) — последовательный подход с четкими фазами Agile — итеративный, гибкий подход с частыми релизами RAD — быстрая разработка приложений DevOps — интеграция разработки и операций
Методы моделирования
Как должна выглядеть идеальная команда на проекте
Идеальная команда на проекте — это не просто набор хороших специалистов, а правильно подобранная группа, где каждый выполняет свою роль, работает эффективно и достигает общих целей. Это результат тщательного подбора людей, структуры, процессов и культуры.
Состав идеальной команды
1. Product Manager (PM) / Product Owner (PO)
Роль:
Качества:
2. System Architect / Lead Developer
Роль:
Разница между User Story и функциональным требованием
Это два различных подхода к описанию возможностей системы, отличающихся форматом, уровнем детализации и философией разработки.
User Story (Пользовательская история)
User Story — это описание функциональности с точки зрения пользователя, используется в Agile-подходе:
Функциональное требование
Функциональное требование (Functional Requirement) — это формальное, детальное описание того, что система должна делать:
Нефункциональные требования для отображения суммы в иностранной валюте
Это хороший пример задачи, где NFR часто игнорируют, но они оказывают большое влияние. Поделюсь как я бы подошел к этому вопросу.
Сначала: Функциональные требования
FR-001: Currency Display
Пример:
Base amount: 100 USD
User selects: EUR
Exchange rate: 1 USD = 0.92 EUR
Displayed: EUR 92.00
Теперь: Нефункциональные требования
NFR-CUR-001: Accuracy (Точность)
Requirement:
Currency conversion must be accurate to 2 decimal places
for standard currencies, 0-3 for others.
Rounding rule: HALF_UP (standard for finance)
Example: EUR 92.456 -> EUR 92.46
Acceptable rounding error: 0.01 (0.01% of amount)
For $1000 order, max error: $0.10
Техники выявления требований в моей практике
Основные методы
Интервью (1-на-1 и групповые)
Анализ документов (Document Analysis)
Наблюдение (Observation)
Плюсы и минусы NoSQL БД
Плюсы NoSQL
Масштабируемость:
Гибкость схемы:
Производительность:
Распределённость:
Минусы NoSQL
Отсутствие ACID:
Дублирование данных:
Отсутствие JOIN'ов:
Обучение:
Рекомендации
NoSQL хороша для масштабируемости и гибкости SQL лучше для консистентности и сложных запросов
Источники требований в системном анализе
Доступ к качественным источникам требований — ключевой фактор успешной разработки системы. От правильной идентификации всех источников зависит полнота и точность требований.
Основные категории источников
Стейкхолдеры (Stakeholders)
Методы сбора требований
Интервью (Interviews)
Какие HTTP-методы являются безопасными
Безопасный HTTP-метод — это метод, который не должен изменять состояние ресурса на сервере. Безопасные методы выполняют только операции чтения, не создание, обновление или удаление данных.
Безопасные HTTP-методы
1. GET — получить ресурс
Самый безопасный метод. Используется для чтения данных без побочных эффектов.
GET /api/v1/users/123
GET /api/v1/products?category=electronics
Свойства:
2. HEAD — как GET, но без тела ответа
Идентичен GET, но сервер возвращает только заголовки без тела ответа. Полезен для проверки наличия ресурса и его метаданных.
HEAD /api/v1/files/document.pdf
Ответ (без содержимого файла):
200 OK
Content-Length: 1024000
Content-Type: application/pdf
Last-Modified: 2025-03-20
Мероприятия в Scrum
Scrum определяет набор обязательных мероприятий (ceremonies), которые структурируют работу команды. Каждое мероприятие имеет чёткую цель, продолжительность и формат.
1. Product Backlog Refinement (Уточнение бэклога)
Назначение: Подготовка элементов бэклога к спринту
Результат: Бэклог становится понятнее, задачи готовы к планированию спринта
2. Sprint Planning (Планирование спринта)
Назначение: Определить, какую работу команда выполнит в спринте
Связь многие-ко-многим (Many-to-Many) в реляционных БД
Связь многие-ко-многим (Many-to-Many, M2M) — это один из самых важных типов отношений в реляционной модели данных. Например, студент может посещать несколько курсов, а каждый курс может быть посещён многими студентами.
Проблема и её решение
Почему нельзя просто так хранить?
Если в таблице students добавить колонку course_ids, то:
Решение: промежуточная таблица связи (junction table, pivot table, bridge table)
Классический подход: Junction Table
Структура:
-- Таблица студентов
CREATE TABLE students (
id INT PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(100)
);
-- Таблица курсов
CREATE TABLE courses (
id INT PRIMARY KEY,
title VARCHAR(100),
description TEXT
);
Клиент (Client) в архитектуре систем
Клиент — это программа, приложение или устройство, которое инициирует запрос на услугу у другой программы, приложения или устройства (сервера). Концепция клиента является одной из ключевых в архитектуре распределенных систем и сетевых приложений.
Определение и роль клиента
В модели клиент-сервер клиент:
Типы клиентов
Браузер:
Примеры:
Структура таблицы базы данных: правильный подход
Этот вопрос часто подразумевает конкретную предметную область. Я дам универсальный пример с объяснением принципов, применимых к любым таблицам.
Принципы проектирования таблиц
1. Нормализация (Normal Forms)
2. Типизация
3. Ограничения (Constraints)
Пример 1: Таблица пользователей (Users)
Плюсы и минусы SQL баз данных
Плюсы SQL БД
ACID-гарантии и надёжность
Структурированность и схема
Мощный язык запросов (SQL)
Передача бинарных файлов в POST: технические подходы
Передача бинарных файлов (изображения, документы, видео, архивы) — частая задача в API. Существует несколько подходов, каждый с преимуществами и недостатками.
Подход 1: multipart/form-data (Рекомендуется)
Описание
Это стандартный способ передачи файлов через формы в HTML и API. Данные кодируются как multipart MIME-сообщение.
Пример HTTP запроса:
POST /api/v1/upload HTTP/1.1
Host: api.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
Content-Length: 12345
------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg
[BINARY DATA HERE]
------WebKitFormBoundary
Content-Disposition: form-data; name="description"
My photo
------WebKitFormBoundary--
Виды API (Application Programming Interfaces)
API — это интерфейс взаимодействия между программами. В системном анализе мы различаем API по архитектурному стилю, протоколу, области применения и методу коммуникации.
1. REST API (Representational State Transfer)
Определение: Architectural style для построения web сервисов, основанный на HTTP и стандартных операциях CRUD (Create, Read, Update, Delete).
Характеристики:
Пример из практики:
О себе
Я — System Analyst с более чем 10 лет опыта в разработке и анализе сложных корпоративных систем. Специализируюсь на проектировании масштабируемых архитектур и оптимизации бизнес-процессов.
Профессиональный путь
Мой путь в IT начался с разработки на Java, что дало мне понимание кода и технических ограничений. Позже я перешёл в системный анализ, где смог объединить технические знания с навыками взаимодействия с бизнесом.
Ключевые позиции:
Этот путь дал мне уникальную перспективу: я понимаю проблемы разработчиков изнутри и могу писать анализ, который реально реализуем.
Области экспертизы
Транзакции в базе данных и свойства ACID
Транзакция — это фундаментальная концепция в системах управления базами данных (СУБД). Она гарантирует надежность и целостность данных при выполнении сложных операций, особенно когда одновременно работают несколько пользователей.
Определение транзакции
Транзакция — это логическая единица работы, состоящая из одной или нескольких операций БД (INSERT, UPDATE, DELETE, SELECT), которые либо выполняются полностью, либо откатываются полностью. Либо все, либо ничего.
Пример транзакции (перевод денег):
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
Это гарантирует, что либо оба счета обновлены, либо ни один не обновлен (если случилась ошибка).
Зачем нужны транзакции?
Инкапсуляция: один из основных принципов ООП
Инкапсуляция — это принцип объектно-ориентированного программирования, который заключается в скрытии внутренних деталей реализации объекта и предоставлении контролируемого доступа к его данным и методам.
Суть инкапсуляции
Простое объяснение: Инкапсуляция — это как фасад компании. Снаружи вы видите красивый офис и рецепцию, но не видите внутреннюю структуру: где хранятся документы, как организована работа. Компания предоставляет вам необходимые услуги через определённые каналы, не раскрывая все внутренние процессы.
Определение: Инкапсуляция — объединение данных (свойств) и методов, которые работают с этими данными, в одной сущности (классе) с контролем доступа к этим данным.
Основные принципы инкапсуляции
1. Скрытие данных (Data Hiding)
Что записать в техническое задание при противоречии требований?
Краткий ответ
Никогда не скрывай противоречие в TZ. Документируй его явно с решением или вариантами.
Типы противоречий
1. Функциональные противоречия
"Система должна быть offline-first"
VS
"Система должна всегда синхронизировать в реальном времени"
2. Производительность vs Функциональность
"Response < 100ms"
VS
"Поддержка 1M records с complex filtering"
3. Security vs Usability
"Максимальная безопасность"
VS
"Пользователи не хотят вводить пароль каждый раз"
4. Scope vs Budget
"Нужно 20 features"
VS
"Бюджет на 5 features"
5. Scope vs Timeline
"Все features важны"
VS
"Нужно launch через месяц"
Case 1: Противоречие в Performance
Реальный пример:
OLD requirement (from Product Manager):
FR-001: "System must export 100k records in < 5 seconds"
Мой опыт участия в проектировании архитектуры
Да, я много раз участвовал в проектировании архитектуры систем. На самом деле, это один из ключевых аспектов работы системного аналитика. Поделюсь опытом.
Роль системного аналитика в архитектуре
Часто люди думают что архитектуру проектирует только архитектор или lead developer. Это неправда. System Analyst играет важную роль:
Что делает Systems Architect:
Что делает Systems Analyst:
My Role: Я работаю ВМЕСТЕ с архитектором. Он выбирает "как", я выявляю "почему" и "какие требования это должна удовлетворить".
Опыт работы с Agile: от scrum мастера к трансформации
Контекст: водопад vs Agile
В самом начале моей карьеры компания работала full waterfall:
Проблемы:
Это подтолкнуло компанию к Agile.
Мой путь в Agile
Что я изучал:
SCRUM Framework:
1. Roles:
- Product Owner (приоритизирует)
- Scrum Master (facilitator)
- Development Team (разработчики)
2. Ceremonies:
- Sprint Planning (планирование на 2 недели)
- Daily Standup (15 минут каждый день)
- Sprint Review (показ того что сделали)
- Sprint Retrospective (что улучшить)
Опыт написания запросов (RFP, Requirements Specification, Design Docs)
Введение
В роли System Analyst'а я писал сотни различных "запросов" — от простых User Stories до 50+ страничных Design Documents. Это критически важный skill, потому что плохой запрос = плохой результат.
Типы запросов, которые я пишу
1. RFP (Request for Proposal) — 20 проектов
2. Requirements Document (SRS) — 50+ проектов
3. Design Document (Architecture + Functional Design) — 30+ проектов
4. User Stories + Acceptance Criteria — сотни
Когда Использовать SQL БД: Полное Руководство
SQL базы данных (реляционные БД) — это "рабочая лошадка" большинства приложений. Важно понимать, когда они оптимальны, а когда нужны альтернативы.
Когда SQL — Идеальный Выбор
1. Структурированные Данные с Четкой Схемой
Применимо:
Пример:
CREATE TABLE customers (
id INTEGER PRIMARY KEY,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE,
country VARCHAR(2),
created_at TIMESTAMP
);
SQL отлично подходит, потому что:
2. Когда Важны ACID Гарантии
ACID = Atomicity, Consistency, Isolation, Durability
Типы соединения таблиц (JOIN) в SQL
Основной синтаксис
SELECT columns
FROM table1
JOIN table2 ON table1.id = table2.table1_id;
1. INNER JOIN (внутреннее соединение)
Что возвращает: только совпадающие строки из обеих таблиц
Синтаксис:
SELECT q.title, a.text, u.name
FROM Question q
INNER JOIN Answer a ON q.id = a.question_id
INNER JOIN User u ON a.user_id = u.id;
Диаграмма:
Question Answer
┌────┐ ┌────┐
│ Q1 │ ──→ │ A1 │ (совпадение)
│ Q2 │ ──→ │ A2 │ (совпадение)
│ Q3 │ X │ │ (Q3 без ответов - не будет в результате)
└────┘ └────┘
Результат: Q1-A1, Q2-A2 (только пересечение)
Визуально (диаграмма Венна):
table1 table2
┌────────────┐
│ MATCH │
│ (INNER) │
└────────────┘
Типы данных SQL: полный справочник
Типы данных — это основа структуры БД. Рассмотрю все основные типы, их особенности и когда их использовать.
Категория 1: Числовые типы
Целые числа (Integer)
TINYINT → -128 до 127 (1 байт) [MySQL]
SMALLINT → -32768 до 32767 (2 байта) [PostgreSQL, MySQL]
INTEGER / INT → -2^31 до 2^31-1 (4 байта) [Стандарт]
BIGINT → -2^63 до 2^63-1 (8 байт) [PostgreSQL, MySQL]
Примеры использования:
TINYINT: статус (0=активный, 1=удален)
SMALLINT: количество товара (0-1000)
INT: ID пользователя (обычно используют)
BIGINT: timestamp в миллисекундах, большие ID
Числа с плавающей точкой (Float/Decimal)
FLOAT → приблизительные (4 байта)
DOUBLE → приблизительные (8 байт)
DECIMAL(p, s) → точные (p = всего цифр, s = после запятой)
NUMERIC(p, s) → синоним DECIMAL
Как системный аналитик может проверить сетевую доступность эндпоинта?
Проверка сетевой доступности — критическая часть диагностики и мониторинга приложений. Существует множество инструментов и подходов для определения, доступен ли эндпоинт.
1. Утилиты командной строки
Проверяет доступность хоста на уровне ICMP:
ping google.com
# PING google.com (142.251.46.14): 56 data bytes
# 64 bytes from 142.251.46.14: icmp_seq=0 ttl=119 time=15.234 ms
Что проверяет: базовая доступность хоста Ограничения: не тестирует конкретный порт или HTTP
Проверяет доступность конкретного портa:
telnet api.example.com 443
# Connected to api.example.com
# Escape character is .^].
Плюсы: простая, показывает, открыт ли порт Минусы: устаревшая, не работает с HTTPS
Проверяет HTTP эндпоинт и читает ответ:
curl -v https://api.example.com/health
# Получаем статус код, headers, body
Подсчёт количества строк в таблице
Подсчёт строк в таблице - частая операция. Существует несколько способов в зависимости от требований.
1. COUNT(*) - базовый метод
Самый простой способ:
SELECT COUNT(*) FROM users;
Результат: вернёт одно число, например 1000
С алиасом для читаемости:
SELECT COUNT(*) as total_count FROM users;
COUNT(*) считает все строки, включая NULL значения.
2. COUNT(column_name) - считаем не-NULL значения
Различие между COUNT(*) и COUNT(column):
-- Считает все строки (1000)
SELECT COUNT(*) FROM users;
-- Считает только строки где phone не NULL (950)
SELECT COUNT(phone) FROM users;
Пример:
-- Сколько пользователей указали телефон
SELECT COUNT(phone) FROM users;
-- Сколько пользователей не указали телефон
SELECT COUNT(*) - COUNT(phone) FROM users;
3. С условиями WHERE
Как понять, что работа над требованием закончена
Это один из критичных вопросов в системном анализе. Неправильное определение момента завершения приводит к недокомплекту функционала или излишней работе. За 10+ лет выработал четкие критерии.
1. Критерии приёмки (Acceptance Criteria)
Всё начинается с документирования требования.
Перед началом разработки вместе с product owner я определяю чёткие acceptance criteria:
Требование: "Пользователь может фильтровать заказы по дате"
Acceptance Criteria:
☑ Есть UI элемент для выбора диапазона дат
☑ Фильтр работает при выборе "от" даты
☑ Фильтр работает при выборе "до" даты
☑ Фильтр работает при выборе обоих дат
☑ Если нет данных в диапазоне — показывается "нет заказов"
☑ URL содержит параметры фильтра (для шеринга)
☑ Работает на мобильных устройствах
☑ Performance: загрузка < 500ms для 10,000 заказов
Без AC очень легко разойтись с ожиданиями.
2. Чеклист разработчика
Как перечитать сообщения с момента сбоя в Kafka
Kafka — это распределённая система потоковой обработки данных, которая гарантирует, что сообщения не теряются. Одна из её главных особенностей — это возможность перечитывать сообщения с любой точки в истории. Это критично при сбоях, когда нужно восстановить обработку с того места, где она прервалась.
Основные концепции Kafka
Offset — это порядковый номер сообщения в партиции. Kafka отслеживает, какой offset прочитала консьюмер-группа.
Partition 0: [msg0] [msg1] [msg2] [msg3] [msg4] [msg5]
offset: 0 1 2 3 4 5
↑
Current offset (2)
Коммит offset — это сохранение информации о том, какие сообщения уже обработаны.
Consumer Group — это группа консьюмеров, которые вместе обрабатывают сообщения из топика. Kafka отслеживает, какой offset обработала каждая группа.
Структура JSON: фундаментальные компоненты
JSON (JavaScript Object Notation) — это простой, текстовый формат обмена данными. Несмотря на кажущуюся простоту, его структура строга и состоит из нескольких базовых элементов.
Основные типы данных JSON
1. Объект (Object)
Упорядоченная коллекция пар ключ-значение, заключённая в фигурные скобки.
{
"name": "John",
"age": 30,
"active": true
}
Особенности:
2. Массив (Array)
Упорядоченная коллекция значений, заключённая в квадратные скобки.
[
"apple",
"banana",
"orange"
]
Массивы могут содержать:
Примитивные типы значений
Строка (String)
Текст в двойных кавычках. Поддерживает Unicode и escape-последовательности.
"Hello, World!"
"Привет"
"Line 1\nLine 2"
Когда использовать NoSQL БД?
NoSQL (Not Only SQL) — это категория баз данных, которые отличаются от традиционных реляционных СУБД структурой данных, моделью консистентности и масштабируемостью. Выбор между SQL и NoSQL — критичное архитектурное решение.
Типы NoSQL БД
1. Document-oriented (Документориентированные)
2. Key-Value (Ключ-значение)
3. Column-Family (Колоночные)
4. Graph (Графовые)
Когда использовать NoSQL
✅ Используй NoSQL когда:
Пользовательские требования (User Requirements)
Пользовательские требования — это описание того, что должна делать система с точки зрения конечного пользователя. Это основа для разработки любого системного решения, и как системный аналитик, я считаю работу с пользовательскими требованиями одной из наиболее критических задач.
Определение и назначение
Пользовательские требования — это описание возможностей и функций, которые система должна предоставить пользователю для решения его задач. Они отвечают на вопрос: «Что должна делать система?», а не «Как это реализовать?»
В отличие от функциональных требований (которые детально описывают реализацию), пользовательские требования написаны на понятном для бизнеса и пользователя языке.
Характеристики пользовательских требований
Способы документирования требований
Документирование требований — это ключевой этап в системном анализе. Правильно задокументированные требования снижают риск неправильного понимания, помогают управлять изменениями и служат основой для разработки, тестирования и приемки системы.
Основные форматы документирования
1. Software Requirements Specification (SRS)
Это наиболее формальный и полный документ, содержащий все требования проекта.
Структура SRS:
1. Введение
- Назначение документа
- Область применения
- Определения, акронимы, сокращения
2. Общее описание
- Контекст продукта
- Характеристики пользователей
- Ограничения
3. Специфические требования
3.1 Функциональные требования
3.2 Нефункциональные требования
3.3 Требования данных
3.4 Требования интерфейса
4. Приложения
- Примеры use cases
- Диаграммы
- Глоссарий
Что такое требования?
Требования — это чётко определённые, проверяемые утверждения о том, что должна делать система, как она должна работать и какие ограничения она должна соблюдать. Требования — это мост между бизнесом и технической разработкой, они формализуют видение заинтересованных лиц в документе, который может быть реализован разработчиками.
Определение требований
Требование — это:
Типы требований
Описывают, что система должна делать: её функции, возможности и поведение.
Методы сбора требований в System Analysis
Наличие грамотного набора методов критично для успеха проекта, так как неправильно собранные требования приводят к переделкам и превышению бюджета.
1. Интервьюирование (Interviews)
Суть: прямое общение со стейкхолдерами для выявления их потребностей и боли.
Типы:
Плюсы: глубокое понимание контекста, выявление скрытых потребностей Минусы: субъективность, нелинейность, требует опыта
На практике: использую полуструктурированные интервью — готовлю чек-лист вопросов, но даю пространство стейкхолдерам делиться в свободной форме.
2. Фокус-группы (Focus Groups)
Суть: групповое обсуждение с несколькими ключевыми пользователями одновременно.
RESTful принципы
REST (Representational State Transfer) — это архитектурный стиль для разработки веб-сервисов, предложенный Роем Филдингом в 2000 году. Это не протокол и не стандарт, а набор принципов и ограничений для проектирования API. Большинство современных веб-сервисов используют REST или претендуют на это.
Что такое RESTful API
RESTful API — это API, который следует принципам REST для работы через HTTP. Вместо вызова функций (как в RPC), вы манипулируете ресурсами (представлениями состояния).
6 принципов REST архитектуры