forked from GitGud/alfa_test_project
102 lines
14 KiB
Markdown
102 lines
14 KiB
Markdown
# Тестовый проект для Python-разработчика
|
||
|
||
Привет! Круто, что ты решил присоединиться к нашей команде. Меня зовут Артем, я собираю команду крутых разработчиков(или тех, кто ими хочет стать). Вместе мы решаем сложные и комплексные задачи. Мы стараемся не брать в работу совсем простые проекты(в духе - сделать сайт с админкой), каждый проект для нас - это вызов в первую очередь к самим себе. Конечно, у нас порой попадаются рутинные задачки, куда без них. Но едва ли проекты, которые мы делаем, можно назвать тривиальными. Наши приоритеты - свобода и профессионализм.
|
||
|
||
Сейчас я расскажу тебе как всё устроено у нас в команде в плане разработки, а затем расскажу что нужно сделать, чтобы к нам попасть.
|
||
|
||
## Процесс разработки
|
||
|
||
Коммуникацию с тобой будет держать проект-менеджер. Это твой бро и он любит тебя! ПМ обычно ставит задачи в таск-трекере. В целом процесс состоит из простых этапов:
|
||
- **Постановка задачи** (ПМ описывает задачу и ставит вас исполнителем)
|
||
- **Примерная оценка** (ожидаем от тебя уточнения по задаче - ты должен четко понимать что нужно будет сделать и как это сделать, и примерную оцену - это нужно для утверждения эстимейтов и бюджета с заказчиком и планирования загруза)
|
||
- **Утверждение** (ПМ утверждает затраты по задачам и подтверждает задачу в план или просит уточнения)
|
||
- **Планирование** (ПМ ставит задачу в план, можно приступать к её реализации)
|
||
- **Решение задачи** (тут ожидаем от тебя красивого решения задачи. Если нужна помощь или возник вопрос/переоценка/что-угодно другое - сообщи ПМ. Мы за открытость, а поскольку команда удаленная нам важна коммуникация в первую очередь)
|
||
- **Задача решена** (ты выгружаешь решение на тестовое окружение, меняешь статус по задаче, задача переходит в тестирование в первую очередь к ПМ и/или на code-review к ответственным лицам)
|
||
- **Подтверждение ответственными лицами** (ПМ или тим-лид подтверждает решение и дает добро на выгрузку в продакшен. Некоторые проекты мы не можем выгружать в определенное время(высокая нагрузка/зависимость от других задач), поэтому ПМ может согласовать выгрузку в определенную дату. Обычно выгрузка - это merge ветки задачи/тестового окружение в продакшен)
|
||
|
||
### Про окружение и CI/CD
|
||
На всех проектах мы имеем тестовое окружение, где другие участники процесса могут проверить результаты работы команды. Мы также следуем концепции CI/CD, делая всё, чтобы ребята могли выгружать код используя только гит. Если что-то будет необходимо сделать с сервером до/после выгрузки - сообщи об этом ПМ, он решит этот вопрос или любой другой.
|
||
|
||
### Про эстимейты и декомпозицию
|
||
Стуктурирование очень важно при работе со сложными/комплексными задачами. Поэтому мы просим раскладывать все задачи на отрезки длиной от 15 минут до 2 часов. Если задача занимает 2+ часов, то она должна быть декомпозирована на более мелкие. Задачи длиной меньше 15 минут в нашей вселенной быть не может :)
|
||
|
||
### Про коммуникации
|
||
Поскольку у нас удаленка, нам очень важна коммуникация и прозрачность процессов. И тут нельзя не сказать о важности ПМ - очень важный человек, строй с ним хорошую коммуникацию. Его задача - заботится о тебе, защищая от натисков внешнего мира(например, заказчика). Дружи с ПМ и веди с ним активную коммуникацию, он ценит тебя и то, что ты делаешь больше, чем кто бы то ни было другой.
|
||
|
||
Кроме того у нас есть некоторые ежедневные процессы, которых просим придерживаться:
|
||
|
||
- **Daily** (каждый день коммуникация с ПМ и командой по 10-20 минут для синхронизации по задачам)
|
||
- **Ежедневный чек по задачам и затраченному времени** (каждый вечер просим потратить время на то, чтобы отписаться по задачам, которые были взяты в работу и выполнены или не доделаны - сколько затратил времени, что осталось доделать. Также просим запушить в гит результат своей работы каждый день, даже если работа еще не закончена - создать отдельную ветку под каждую задачу -- **это единственный элемент контроля твоей работы, который мы требуем**. Если день был не очень продуктивный или что-то пошло не так - сообщи об этом ПМ. Мы лояльны и открыты, нам важно, чтобы работа шла и была прозрачна)
|
||
|
||
Поскольку у нас удаленка и свобода в приоритете, то мы ожидаем, что ты будешь на связи с 9-00 до 18-00 по МСК. Когда ты будешь решать задачи - выбираешь ты. Мы просим:
|
||
- постараться попадать в свои же оценки
|
||
- быть доступным для коммуникаций в рабочее время(либо предупреждать ПМа если куда-то нужно отойти, всякое бывает)
|
||
- быть честным, открытым, активным и позитивным ;)
|
||
|
||
# Тестовое задание
|
||
|
||
Мы не сторонники интервью и сложных тестовых на часы. Предлагаем выполнить простые задачки в рамках имеющегося проекта. Проверять их будем двумя путями:
|
||
- тесты
|
||
- просмотр кода
|
||
|
||
## О проекте
|
||
Итак, перед тобой проект, на котором подключены FastAPI и Django одновременно. Django используется только как ORM и админка, FastAPI используется для запросов. Мы не фанаты DRF, почти все проекты пишем в связке какой-то фронт(Vue/React) + API(чаще всего не REST), поэтому использование Class-based Views пригодится максимум для админки. Собственно, от Django кроме ORM и умения рулить админкой мы больше ничего и не берем. Если не сталкивался с FastAPI - не беда, наверняка ты уже пробовал Flask, они очень похожи.
|
||
|
||
Дисклеймер: не пытайся оценить структуру проекта, это всего лишь тестовое, которое должно решаться парой десятков строк кода.
|
||
|
||
Мы храним базу данных игроков и игр. В игре может быть не более 5 игроков. Игроки и игры создаются при помощи API-вызовов с применением аутентификации по методу JWT(уже внедрено, читай OpenAPI-документацию доступную по запросу на http://localhost:8000/docs).
|
||
|
||
## Инфраструктура
|
||
Мы используем активно Docker и Docker-compose для поднятия инфраструктуры, используй их.
|
||
`docker-compose up -d` поднимет всю инфраструктуру проекта и проект будет доступен по http://localhost:8000/. Правки применятся автоматически(благодаря --reload(command в docker-compose), файлы внутри контейнеров и на локальной машине синхронизированы через volumes(docker-compose).
|
||
Внутрь контейнера с python можно попасть, используя команды:
|
||
```
|
||
docker ps #отобразит список всех контейнеров
|
||
docker exec -ti <container_id> bash #войдет в запущенный контейнер для выполнения команд, например - создания superuser
|
||
````
|
||
|
||
## Задачи в рамках тестового задания:
|
||
|
||
- [ ] Необходимо отобразить модели игрока и игр в админке (http://localhost:8000/django/admin)
|
||
|
||
*Задача на понимание моделей Django, миграциями, работы с админкой и docker*
|
||
|
||
ТЗ: отобразить в списке игроков: имя, email, дату и время создания игрока, дату и время изменения игрока(в нашем случае только через админку); добавить поиск по имени или email. Отобразить в списке игр название игры и имена игроков через запятую(отдельным столбцом), дату и время создания игры, дату и время изменения игры. На странице редактирования игры отобразить inline'ами всех привязанных игроков.
|
||
*Модели менять можно!*
|
||
|
||
Что будем оценивать:
|
||
* создана ли миграция?
|
||
* выполнены ли все условия ТЗ?
|
||
* как выполнен reverse lookup?
|
||
|
||
- [ ] Задваивание игроков с одинаковым name и email
|
||
|
||
*Задача на понимание FastAPI, валидации и транзакций*
|
||
|
||
ТЗ: при создании игрока(/new_player) его имя и email должны быть уникальны. Имя должно содержать только цифры от 0 до 9 и только буквы от a до f.
|
||
Если пользователь с таким email и name уже существует, необходимо вернуть ошибку с HTTP-кодом 400, status = "error", текстом "player with such name or email already exists". Аналогичную ошибку необходимо вернуть при ошибки валидации имени пользователя или e-mail'а с указанием соответствующего текста ошибки
|
||
|
||
Что будем оценивать:
|
||
* возможна ли race condition?
|
||
* выполнены ли все условия ТЗ?
|
||
* можно ли получить 500 ошибку при отправке данных, величина которых не предусмотрена БД?
|
||
|
||
- [ ] Реализовать логику для метода /add_player_to_game
|
||
|
||
*Задача на работу с ManyToMany Django ORM, валидацией FastAPI, транзакциями*
|
||
|
||
ТЗ: при запросе игрок с указанным id должен добавляться в игру с указанным id. Если игрока или игры с заданными id не существует, должна возвращаться ошибка с HTTP-кодом 400, status = "error" и соответствующим текстом. Количество игроков в одной игре не более 5.
|
||
|
||
Что будем оценивать:
|
||
* возможна ли race condition?
|
||
* выполнены ли все условия ТЗ?
|
||
* можно ли получить 500 ошибку?
|
||
* что произойдет при добавлении одного игрока два и более раз?
|
||
|
||
## Как сдавать тестовое
|
||
Перешлите архив с вашими доработками нашему менеджеру, мы дадим ответ на следующий день.
|
||
|
||
Название архива должно содержать ваше имя и фамилию. ВасяПономорев.zip / VasyaPonomorev.zip
|
||
|
||
Спасибо за внимание ;) |