Здесь самостоятельные задания с учебными данными. Сначала сделайте свою попытку, затем проверьте крайние случаи и откройте подсказку. Время — ориентир; для проекта учитывайте отдельное время на тесты и оформление.
Как выбрать практику · Карта промахов
Прокрутите таблицу по горизонтали →
| Задание | Этап | Ориентир |
|---|---|---|
| CLI для смены в кафе | Базовый Python | 180 мин |
| Планировщик работ мастерской | Инженерный Python | 360 мин |
| API расчёта закупки ингредиентов | HTTP и API | 420 мин |
| Приёмка и ремонт техники | Web-фреймворк | 600 мин |
| Версии инструкций для оборудования | Web-фреймворк | 720 мин |
| Бронирование занятий с напоминаниями | Async и фоновые задачи | 900 мин |
CLI для смены в кафе
Сделайте консольное приложение для учёта заказов одной смены. Меню содержит код блюда, цену в копейках и список аллергенов. Команды добавляют позицию, меняют количество, удаляют её, печатают чек и закрывают заказ. После закрытия заказ нельзя редактировать. Пустой чек закрывать нельзя. Состояние активного заказа сохраняется в JSON между запусками. Данные меню и идентификатор смены задаются локальным файлом; никакого внешнего API или БД на этом этапе.
Проверка результата
- Покажите сценарий: создать → изменить → перезапустить → закрыть → отклонить изменение.
- Ошибочный код блюда, отрицательное количество и повреждённый JSON дают понятную ошибку без потери последнего корректного состояния.
- README содержит команды запуска и данные для воспроизведения.
Подсказка — после своей попытки
Сначала отделите команды ввода от функций изменения заказа.
Усложнение: Добавьте отмену последнего изменения до закрытия заказа и тест на восстановление состояния.
Планировщик работ мастерской
Создайте модель мастерской: работы имеют длительность, необходимые навыки и зависимости от других работ; сотрудники имеют набор навыков. В дискретный момент свободному сотруднику назначается готовая работа, для которой завершены все зависимости. При равенстве выбирайте меньший id работы, затем меньший id сотрудника. Сотрудник занят до окончания работы. Модель не зависит от консоли: отдельный рендерер показывает расписание. Ввод с циклом зависимостей или задачей без подходящего сотрудника должен завершаться понятной ошибкой, а не бесконечным циклом. Длительность — положительное целое число шагов; сотрудник должен иметь все навыки работы.
Проверка результата
- Одна работа не исполняется дважды и сотрудник не делает две работы одновременно.
- Работа не начинается до завершения зависимостей.
- Повтор запуска на одинаковых данных даёт одинаковое расписание; проверены тупик и пустой ввод.
Подсказка — после своей попытки
Разделите готовность работы, выбор исполнителя и продвижение времени.
Усложнение: Сравните жадный план с альтернативой по общему времени; не обещайте оптимальность без доказательства.
API расчёта закупки ингредиентов
Ресторан хранит рецепты и размеры упаковок ингредиентов. Реализуйте HTTP API каталога рецептов и расчёта закупки на заданное число порций. Для каждого ингредиента верните нужные граммы, количество целых упаковок и остаток после готовки. Например, 7 порций по 120 г при упаковке 500 г требуют 2 упаковки и оставляют 160 г. Используйте целые граммы и минимальные денежные единицы; сохраняйте каталог в локальной SQL-базе. Фиксируйте контракт запросов, ответы на ошибки и допустимые размеры входа. История складских остатков и списание товаров в этот проект не входят. Число порций — целое от 0 до 10 000; для нуля верните нулевую закупку. Количество граммов в рецепте и размер упаковки положительны.
Проверка результата
- Проверены ровно одна упаковка, переход через границу упаковки и ноль порций.
- Недопустимые значения и отсутствующий рецепт не превращаются в HTTP 200.
- Чистый запуск создаёт схему и пример рецепта; HTTP-тесты проверяют расчёт и ошибки.
Подсказка — после своей попытки
Сначала реализуйте расчёт как чистую функцию, затем добавляйте HTTP и хранение.
Усложнение: Добавьте новый размер упаковки и объясните, когда минимальное количество упаковок отличается от минимальной стоимости.
Приёмка и ремонт техники
Сервис мастерской хранит заявки с переходами new → diagnosed → approved → repairing → ready → delivered. До repairing заявку можно отменить. Начать ремонт разрешено после согласования стоимости владельцем; delivered — только после отметки оплаты. Каждая команда содержит ожидаемую версию заявки; устаревшая версия отклоняется. История переходов хранится в той же SQL-базе. Нужны API, простой экран списка и карточки либо документированные HTTP-сценарии, миграции и тесты правил. Доменная логика проверяется отдельно от framework.
Проверка результата
- Нельзя перескочить через согласование, выдать неоплаченную технику или изменить доставленную заявку.
- Два изменения с одной версией не приводят к потере истории: успешно только одно.
- Изменение состояния и запись истории атомарны; тест проверяет откат.
Подсказка — после своей попытки
Опишите допустимые переходы таблицей до написания endpoint.
Усложнение: Добавьте частичную оплату и пересогласование цены с новым набором тестов.
Версии инструкций для оборудования
Сервис хранит инструкции к оборудованию: каждая новая загрузка создаёт неизменяемую ревизию, одна ревизия помечена текущей. Пользователь видит только оборудование своей команды; редактор загружает версии, читатель скачивает. Метаданные находятся в PostgreSQL, содержимое — в файловом или S3-совместимом хранилище. Переименование отображаемого файла не должно менять storage key. Проверяйте размер и допустимый тип, закрывайте доступ после исключения пользователя из команды. Одинаковые имена в разных командах не конфликтуют. Произвольного дерева папок и публичных ссылок в этом задании нет.
Проверка результата
- Проверены читатель, редактор, чужая команда и бывший участник.
- Сбой сохранения файла не оставляет доступную «готовую» ревизию без содержимого.
- Предыдущая ревизия остаётся скачиваемой после публикации новой; тесты работают на временном хранилище.
Подсказка — после своей попытки
Разделите отображаемое имя, идентификатор ревизии и ключ физического хранения.
Усложнение: Добавьте очистку осиротевших файлов после сбоя без удаления опубликованных ревизий.
Бронирование занятий с напоминаниями
Сервис принимает брони на занятия мастерской, показывает доступную вместимость и отправляет напоминания. API и worker работают отдельными процессами. PostgreSQL хранит брони, задания и исходящие события; брокер или очередь может доставить задание повторно. Внешний поставщик расписания иногда отвечает медленно или ошибкой: используйте заменяемый fake-provider в тестах. Если отмена зафиксирована до начала отправки, напоминание не отправляется. Учебный отправитель принимает ключ идемпотентности и возвращает один результат для всех его повторов. Начните с одной базы и двух процессов; выделение дополнительных сервисов требует объяснения. Docker Compose поднимает всё окружение, CI запускает проверки.
Проверка результата
- Повтор запроса или задания не создаёт вторую бронь и повторный бизнес-эффект.
- Перезапуск worker не теряет задания; провайдер с таймаутом не блокирует API бесконечно.
- Проверены отмена перед отправкой, гонка за последним местом и падение после выполнения до подтверждения.
Подсказка — после своей попытки
Явно опишите границы транзакций и повторов; для реального внешнего отправителя сформулируйте его требования к идемпотентности.
Усложнение: Добавьте измеримые метрики задержки очереди, повторов и ошибок поставщика.