Процесс разработки¶
Общий подход¶
Разработка игры идёт в духе «инкреметального прототипирования», что предполагает прохождение каждой «фичи» через последовательность прототипов, совершенствующих её реализацию. Не делается попыток с первого раза написать самый правильный и самый крутой код. Как следствие:
- новая «фича» реализуется самым простым и понятным образом, без переусложнений и оптимизаций;
- по мере развития игры (и анализа её работы), логика «фичи» уточняется и совершенствуется;
- если «фича» оказывается достаточно независимой, она выделяется в отдельную библиотеку.
Следствием такого подхода является постоянный рефакторинг проекта.
В случае крупных инфраструктурных изменений их допустимо не применять сразу ко всему проекту, а только к тем частям, над которыми идёт работа в настоящий момент. Старый код вычищается тогда, когда появляется необходимость изменения компонента, в котором он находится.
Миграции¶
Миграции схемы базы создаются на основе Django ORM (даже если сам Django больше нигде в сервисе не используется).
Работа с версиями¶
Разработу ведём по git-flow:
- http://nvie.com/posts/a-successful-git-branching-model/
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
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.
- если имя переменной является модулем верхнего уровня стандартной библиотеки, то он импортируется.