alfa_test_project/README.md
2023-09-08 10:54:04 +04:00

102 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Тестовый проект для 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
Спасибо за внимание ;)