From 2d9bfd84aa46f04d3d20423f03ce15087f3ad14b Mon Sep 17 00:00:00 2001 From: Andrey Epifancev Date: Wed, 13 Aug 2025 17:37:19 +0400 Subject: [PATCH] vault backup: 2025-08-13 17:37:19 --- .../Задачи/💼 Прикладная задача для Middle разработчика.md | 482 +++++++++++++++++- 1 file changed, 457 insertions(+), 25 deletions(-) diff --git a/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md b/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md index f845d6c..3229f0c 100644 --- a/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md +++ b/💼 Работа/Собеседования/Лето 2025/Задачи/💼 Прикладная задача для Middle разработчика.md @@ -1,38 +1,470 @@ -## 📝 Задача: Система управления событиями +### 📝 10 прикладных задач для Middle Java-разработчика + +## 🎯 Задача 1: Система управления складскими операциями ### **Условие:** -Вы разрабатываете систему для управления событиями (конференции, вебинары, встречи). Нужно реализовать сервис регистрации участников с учетом следующих требований: +Вы разрабатываете модуль WMS для управления операциями приемки товаров на склад. Система должна обрабатывать поступление товаров от поставщиков. -1. **Событие** имеет: +1. **Поставка** имеет: - - ID, название, описание - - Дату начала и окончания - - Максимальное количество участников - - Статус (DRAFT, PUBLISHED, CANCELLED) -2. **Участник** имеет: + - ID, номер поставки, поставщик + - Плановую и фактическую дату прибытия + - Статус (PLANNED, ARRIVED, IN_PROGRESS, COMPLETED, CANCELLED) +2. **Товарная позиция** содержит: - - ID, имя, email - - Дату регистрации + - SKU товара, плановое количество + - Фактически принятое количество + - Статус приемки (PENDING, ACCEPTED, REJECTED, PARTIAL) 3. **Бизнес-правила:** - - Регистрация возможна только на опубликованные события - - Нельзя зарегистрироваться на событие, которое уже началось - - Нельзя превысить лимит участников - - Один участник может зарегистрироваться на событие только один раз - - При отмене события нужно уведомить всех участников + - Приемка возможна только для прибывших поставок + - Нельзя принять больше товара, чем заявлено в поставке + - При расхождениях создается акт о расхождениях + - После завершения приемки обновляется остаток на складе + - При отмене поставки нужно освободить зарезервированные ячейки ### **Техническое задание:** -**Опишите подход к решению задачи:** +Опишите подход к решению: -1. **Архитектуру приложения** - какие слои нужны -2. **Entity классы** - основные поля и связи -3. **Ключевые методы EventRegistrationService** -4. **Обработку бизнес-правил** - где и как валидировать -5. **REST API endpoints** - какие нужны -6. **Обработку ошибок** - типы исключений -7. **Транзакции** - где нужны и почему -8. **Тестирование** - что важно покрыть тестами +1. **Архитектуру приложения** - слои и компоненты +2. **Entity классы** - модель данных +3. **Ключевые методы ReceivingService** +4. **Валидацию бизнес-правил** +5. **REST API endpoints** +6. **Обработку исключений** +7. **Управление транзакциями** +8. **Стратегию тестирования** -**Время на выполнение:** 25 минут +**Время:** 25 минут + +--- + +## 🎯 Задача 2: Система уведомлений с приоритизацией + +### **Условие:** + +Разрабатывается сервис уведомлений для корпоративного приложения. Система должна отправлять уведомления различными каналами с учетом приоритетов. + +1. **Уведомление** содержит: + + - ID, получатель, тема, содержание + - Приоритет (LOW, NORMAL, HIGH, CRITICAL) + - Каналы доставки (EMAIL, SMS, PUSH) + - Статус (PENDING, SENT, FAILED, DELIVERED) +2. **Шаблон уведомления** имеет: + + - Тип события, шаблон сообщения + - Настройки каналов по умолчанию + - Параметры для подстановки +3. **Бизнес-правила:** + + - CRITICAL уведомления отправляются немедленно всеми каналами + - HIGH - в течение 5 минут, предпочтительные каналы + - NORMAL - батчами каждые 15 минут + - LOW - раз в час группами + - При неудаче повторная отправка через экспоненциальный backoff + - Дедупликация одинаковых уведомлений + +### **Техническое задание:** + +Опишите: + +1. **Архитектуру решения** - асинхронная обработка +2. **Модель данных** - entities и relationships +3. **NotificationService методы** +4. **Стратегию приоритизации** +5. **API для создания уведомлений** +6. **Error handling и retry логику** +7. **Использование очередей** +8. **Тестирование асинхронных процессов** + +**Время:** 25 минут + +--- + +## 🎯 Задача 3: Система управления задачами роботов + +### **Условие:** + +Создается система для управления автоматизированными роботами на складе. Роботы выполняют задачи перемещения товаров между локациями. + +1. **Робот** имеет: + + - ID, тип, текущая локация + - Статус (IDLE, BUSY, MAINTENANCE, ERROR) + - Грузоподъемность, заряд батареи + - Текущая задача +2. **Задача** содержит: + + - ID, тип операции (MOVE, PICK, PLACE) + - Локация источник и назначение + - Приоритет, крайний срок выполнения + - Статус (QUEUED, ASSIGNED, IN_PROGRESS, COMPLETED, FAILED) +3. **Бизнес-правила:** + + - Задачи назначаются ближайшему свободному роботу + - Учитывается грузоподъемность и тип робота + - При низком заряде робот отправляется на зарядку + - Высокоприоритетные задачи могут прерывать обычные + - При сбое задача переназначается другому роботу + +### **Техническое задание:** + +Опишите: + +1. **Системную архитектуру** +2. **Доменную модель** +3. **RobotTaskService логику** +4. **Алгоритм назначения задач** +5. **API для управления роботами** +6. **Обработку сбоев** +7. **Coordination между роботами** +8. **Тестирование concurrent операций** + +**Время:** 25 минут + +--- + +## 🎯 Задача 4: Система управления скидками и промокодами + +### **Условие:** + +Разрабатывается модуль для e-commerce платформы, управляющий скидками и промокодами с различными условиями применения. + +1. **Скидка** имеет: + + - ID, название, описание + - Тип (PERCENTAGE, FIXED_AMOUNT, FREE_SHIPPING) + - Значение скидки + - Период действия, лимит использований +2. **Промокод** содержит: + + - Код, связанная скидка + - Условия применения (минимальная сумма, категории товаров) + - Количество использований на пользователя + - Статус (ACTIVE, EXPIRED, EXHAUSTED) +3. **Бизнес-правила:** + + - Промокод можно применить только к подходящим товарам + - Один заказ может содержать несколько скидок + - Скидки применяются в порядке приоритета + - Нельзя превысить максимальный процент скидки (например, 80%) + - Скидки на доставку несовместимы друг с другом + +### **Техническое задание:** + +Опишите: + +1. **Архитектуру модуля** +2. **Entity модель** +3. **DiscountService функциональность** +4. **Логику валидации и применения** +5. **REST endpoints** +6. **Обработку конфликтов скидок** +7. **Транзакционность операций** +8. **Unit и integration тесты** + +**Время:** 25 минут + +--- + +## 🎯 Задача 5: Система резервирования ресурсов + +### **Условие:** + +Создается система для резервирования переговорных комнат, оборудования и других ресурсов в офисе компании. + +1. **Ресурс** имеет: + + - ID, название, тип (ROOM, EQUIPMENT, VEHICLE) + - Вместимость, локация + - Доступное время работы + - Статус (AVAILABLE, OCCUPIED, MAINTENANCE) +2. **Резервирование** содержит: + + - ID, пользователь, ресурс + - Время начала и окончания + - Цель использования + - Статус (PENDING, CONFIRMED, CANCELLED, COMPLETED) +3. **Бизнес-правила:** + + - Нельзя забронировать занятый ресурс + - Резервирование возможно только на будущее время + - Автоматическая отмена неподтвержденных бронирований через 15 минут + - Recurring резервирования (еженедельные встречи) + - Приоритет для VIP пользователей + +### **Техническое задание:** + +Опишите: + +1. **Системную архитектуру** +2. **Модель данных** +3. **ReservationService методы** +4. **Conflict resolution логику** +5. **API endpoints** +6. **Exception handling** +7. **Scheduled tasks для cleanup** +8. **Тестирование concurrent бронирований** + +**Время:** 25 минут + +--- + +## 🎯 Задача 6: Система мониторинга производительности API + +### **Условие:** + +Разрабатывается система для мониторинга производительности и доступности API endpoints различных микросервисов. + +1. **API Endpoint** имеет: + + - URL, HTTP метод, сервис + - SLA параметры (latency, availability) + - Частота проверок + - Критичность (LOW, MEDIUM, HIGH, CRITICAL) +2. **Метрика** содержит: + + - Timestamp, endpoint, response time + - HTTP статус код, размер ответа + - Статус проверки (SUCCESS, TIMEOUT, ERROR) +3. **Бизнес-правила:** + + - Критичные endpoints проверяются каждые 30 секунд + - Обычные - каждые 5 минут + - При превышении SLA генерируется alert + - Escalation при множественных сбоях + - Автоматическое отключение проблемных endpoints из балансировщика + +### **Техническое задание:** + +Опишите: + +1. **Архитектуру monitoring системы** +2. **Data model** +3. **MonitoringService функции** +4. **Alerting механизм** +5. **Reporting API** +6. **Circuit breaker интеграцию** +7. **Async обработку проверок** +8. **Performance тестирование** + +**Время:** 25 минут + +--- + +## 🎯 Задача 7: Система управления документооборотом + +### **Условие:** + +Создается система для управления корпоративными документами с workflow для согласования и утверждения. + +1. **Документ** имеет: + + - ID, название, тип, версия + - Автор, дата создания + - Содержимое, вложения + - Статус (DRAFT, REVIEW, APPROVED, REJECTED, ARCHIVED) +2. **Workflow** содержит: + + - Этапы согласования + - Участники (роли или конкретные пользователи) + - Условия перехода между этапами + - Временные ограничения +3. **Бизнес-правила:** + + - Документ проходит все этапы workflow по порядку + - На каждом этапе могут быть множественные approvers + - При отклонении документ возвращается автору + - Возможны параллельные и условные этапы + - Автоматическая эскалация при превышении сроков + +### **Техническое задание:** + +Опишите: + +1. **Архитектурный подход** +2. **Domain model** +3. **WorkflowService логику** +4. **State management** +5. **Document API** +6. **Notification интеграцию** +7. **Versioning стратегию** +8. **Тестирование workflow сценариев** + +**Время:** 25 минут + +--- + +## 🎯 Задача 8: Система управления инвентаризацией + +### **Условие:** + +Разрабатывается модуль для проведения инвентаризации товаров на складе с поддержкой различных методов подсчета. + +1. **Инвентаризация** имеет: + + - ID, дата проведения, ответственный + - Тип (FULL, PARTIAL, CYCLE_COUNT) + - Зоны склада для проверки + - Статус (PLANNED, IN_PROGRESS, COMPLETED, CANCELLED) +2. **Позиция инвентаризации** содержит: + + - SKU товара, локация + - Ожидаемое количество (по системе) + - Фактическое количество (по подсчету) + - Расхождение, причина расхождения +3. **Бизнес-правила:** + + - Во время инвентаризации блокируются операции в проверяемых зонах + - Расхождения свыше порога требуют пересчета + - Автоматическая корректировка остатков после утверждения + - Генерация отчетов о расхождениях + - Cycle counting по ABC анализу + +### **Техническое задание:** + +Опишите: + +1. **Системную архитектуру** +2. **Модель данных** +3. **InventoryService методы** +4. **Locking механизм** +5. **API для mobile приложений** +6. **Exception scenarios** +7. **Concurrency control** +8. **Accuracy testing** + +**Время:** 25 минут + +--- + +## 🎯 Задача 9: Система управления конфигурациями + +### **Условие:** + +Создается централизованная система управления конфигурациями для множества микросервисов с поддержкой версионирования и hot reload. + +1. **Конфигурация** имеет: + + - Ключ, значение, тип данных + - Сервис, окружение (dev/test/prod) + - Версия, дата изменения + - Статус (DRAFT, ACTIVE, DEPRECATED) +2. **Изменение конфигурации** содержит: + + - Старое и новое значение + - Автор изменения, комментарий + - Время применения + - Статус применения +3. **Бизнес-правила:** + + - Изменения в prod требуют дополнительного утверждения + - Возможность отката к предыдущей версии + - Валидация значений по схеме + - Encrypted значения для sensitive данных + - Audit trail всех изменений + +### **Техническое задание:** + +Опишите: + +1. **Architecture design** +2. **Data model** +3. **ConfigurationService API** +4. **Validation framework** +5. **REST API design** +6. **Security considerations** +7. **Version control strategy** +8. **Integration testing approach** + +**Время:** 25 минут + +--- + +## 🎯 Задача 10: Система аналитики пользовательского поведения + +### **Условие:** + +Разрабатывается система для сбора и анализа событий пользовательского поведения в веб-приложении с real-time обработкой. + +1. **Событие** имеет: + + - ID, тип события, пользователь + - Timestamp, session ID + - Метаданные (страница, действие, параметры) + - Источник (web, mobile, api) +2. **Сессия** содержит: + + - ID сессии, пользователь + - Время начала и окончания + - Количество событий, страниц + - Conversion events +3. **Бизнес-правила:** + + - События обрабатываются в real-time + - Агрегация метрик по различным измерениям + - Обнаружение аномалий в поведении + - GDPR compliance - возможность удаления данных пользователя + - Retention анализ и funnel metrics + +### **Техническое задание:** + +Опишите: + +1. **Event-driven архитектуру** +2. **Data schema design** +3. **AnalyticsService компоненты** +4. **Real-time processing pipeline** +5. **Query API для дашбордов** +6. **Privacy compliance** +7. **Stream processing с Kafka** +8. **Load testing стратегию** + +**Время:** 25 минут + +--- + +## 📋 Рекомендации по оценке решений + +### **Критерии оценки (для каждой задачи):** + +**Архитектура (25%):** + +- Правильное разделение на слои +- Понимание принципов SOLID +- Separation of concerns + +**Модель данных (20%):** + +- Корректное проектирование entities +- Понимание relationships +- Учет performance implications + +**Бизнес-логика (25%):** + +- Правильная обработка бизнес-правил +- Валидация и error handling +- Edge cases consideration + +**API Design (15%):** + +- RESTful principles +- Proper HTTP methods и status codes +- Request/Response design + +**Качество кода (15%):** + +- Тестирование стратегия +- Transaction management +- Exception handling + +### **Уровни оценки:** + +- **Senior level:** Полное решение со всеми деталями, best practices, edge cases +- **Middle level:** Основные компоненты покрыты, базовая архитектура правильная +- **Junior level:** Базовое понимание задачи, простое решение + +Каждая задача покрывает ключевые навыки Middle разработчика и может быть адаптирована под специфику вашей складской логистики добавлением warehouse-specific деталей. \ No newline at end of file