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

Общий подход

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

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

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

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

Тесты

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

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

Миграции

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

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

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

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

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

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

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

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

  • быть в виде одного патча (pull request должен содержать 1 коммит);
  • быть покрыты тестами;
  • не использовать устаревшую функциональность;
  • применяться к ветке develop (не master!), как и положено по git-flow.

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