Процесс разработки

Общий подход

Разработка игры идёт в духе «инкреметального прототипирования», что предполагает прохождение каждой «фичи» через последовательность прототипов, совершенствующих её реализацию. Не делается попыток с первого раза написать самый правильный и самый крутой код. Как следствие:

  • новая «фича» реализуется самым простым и понятным образом, без переусложнений и оптимизаций;

  • по мере развития игры (и анализа её работы), логика «фичи» уточняется и совершенствуется;

  • если «фича» оказывается достаточно независимой, она выделяется в отдельную библиотеку.

Следствием такого подхода является постоянный рефакторинг проекта.

В случае крупных инфраструктурных изменений их допустимо не применять сразу ко всему проекту, а только к тем частям, над которыми идёт работа в настоящий момент. Старый код вычищается тогда, когда появляется необходимость изменения компонента, в котором он находится.

Тесты

Весь важный код покрывается тестами.

Весь не важный код покрывается тестами по возможности.

Миграции

Миграции схемы базы создаются на основе Django ORM (даже если сам Django больше нигде в сервисе не используется).

Работа с версиями

Разработу ведём по git-flow:

Master ветка всегда содержит в себе текущую рабочую версию проекта (ту, которая сейчас запущена на сайте).

Работа над новой версией ведётся в ветке develop. По завершении работы, делается тег и изменения подливаются в master.

Всю работу надо делать в ветке develop или её ветке. Изменения применять к ней же.

Требования к изменениям

Предлагаемые вами изменения в обязательном порядке должны:

  • быть в виде одного патча (pull request должен содержать 1 коммит);

  • быть покрыты тестами;

  • не использовать устаревшую функциональность;

  • применяться к ветке develop (не master!), как и положено по git-flow.

Желательно, чтобы они сопровождались документацией.

Описание импортов в исходниках на Python

В проекте используется smart_imports. Это упрощает редактирование и анализ кода, плюс, упорядочивает имена сущностей.

Документацию по smart_imports можно найти на странице проекта.

Конфигурация библиотеки (правила импорта) находится в файлах smart_imports.json Например, для основного сайта игры — the_tale — конфигурацию можно найти в файле ./src/the_tale/the_tale/smart_imports.json

В целом, правила импорта можно описать следующими эвристиками (по приоритету):

  • Если имя переменной является стандартным (сторонним) пакетом, оно импортируется напрямую.

  • Если имя переменной находится в списке предопределённых значений, оно импортируется по собственному правилу. Правила определены в smart_imports.json.

  • Если имя переменной совпадает с именем локального модуля (из той же директории), то импортируется модуль.

  • Если имя переменной начинается с имени одного из базовых модулей (например, places_logic, где places — стандартный модуль), то импортируется его подмодуль, определённый после префикса (например, places_logic is the_tale.game.places.logic). Префиксы определены в smart_imports.json.

  • если имя переменной является модулем верхнего уровня стандартной библиотеки, то он импортируется.