470 lines
19 KiB
Markdown
470 lines
19 KiB
Markdown
### 📝 10 прикладных задач для Middle Java-разработчика
|
||
|
||
## 🎯 Задача 1: Система управления складскими операциями
|
||
|
||
### **Условие:**
|
||
|
||
Вы разрабатываете модуль WMS для управления операциями приемки товаров на склад. Система должна обрабатывать поступление товаров от поставщиков.
|
||
|
||
1. **Поставка** имеет:
|
||
|
||
- ID, номер поставки, поставщик
|
||
- Плановую и фактическую дату прибытия
|
||
- Статус (PLANNED, ARRIVED, IN_PROGRESS, COMPLETED, CANCELLED)
|
||
2. **Товарная позиция** содержит:
|
||
|
||
- SKU товара, плановое количество
|
||
- Фактически принятое количество
|
||
- Статус приемки (PENDING, ACCEPTED, REJECTED, PARTIAL)
|
||
3. **Бизнес-правила:**
|
||
|
||
- Приемка возможна только для прибывших поставок
|
||
- Нельзя принять больше товара, чем заявлено в поставке
|
||
- При расхождениях создается акт о расхождениях
|
||
- После завершения приемки обновляется остаток на складе
|
||
- При отмене поставки нужно освободить зарезервированные ячейки
|
||
|
||
### **Техническое задание:**
|
||
|
||
Опишите подход к решению:
|
||
|
||
1. **Архитектуру приложения** - слои и компоненты
|
||
2. **Entity классы** - модель данных
|
||
3. **Ключевые методы ReceivingService**
|
||
4. **Валидацию бизнес-правил**
|
||
5. **REST API endpoints**
|
||
6. **Обработку исключений**
|
||
7. **Управление транзакциями**
|
||
8. **Стратегию тестирования**
|
||
|
||
**Время:** 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 деталей. |