Немного о видах и структуре кода

Код в СуперНове делится на несколько частей. Каждая из них имеет свое происхождение, свою идеологию и свою структуру

1. Оригинальный код XNova 0.8b RageRepack v226. Сборная солянка из оригинального кода XNova 0.8b и кучи модов с просторов интеренета, вбитых в оригинальный движок при помощи лома и какой-то матери. Качество варьируется от "хорошого" (очень, очень мало такого кода!) до "ужасного" и попросту "нерабочего". Например, в коде RR ПОЧТИ ВСЕ параметры, попадающие через запросы GET и POST передавались в БД напрямую без какой либо проверки и обработки! В общем - одна сплошная дыра для SQL-injection и радость малолетней хакервоты (школоты, начитавшейся журнала "Хакер").
2. Этап "совместимости" (от запуска сервера в июне 2009 и примерно до апреля-мая 2010го). Тогда я максимально старался сохранить обратную совместимость с исходным кодом для более легкого встраивания модов из инета. Но за почти год работы сервера не нашлось ни единого мода, который мне бы захотелось встроить в движок, а геммороя из-за неоптимальной архитектуры и грубой состыковки старых модов было предостаточно. И примерно в это время я решил плюнуть на совместимость с родным движком и начать переписывать код целиком. Качество кода этого этапа так же варьируется от "хорошого" (мало) до "ужасного" (к счастью - тоже мало). Нерабочий код был только в тестовых версиях и фиксился до выкатывания на паблик. Алгоритмы максимально наследуют оригиналу, поэтому если были какие-то логические ошибки в расчетах - они успешно повторялись в новом коде.
3. Этап "пре-паблик" (май 2010 - октябрь 2010). Я плюнул на совместимость и принялся переписывать целые подсистемы. Зачастую происходило так - сообщени о баге или заявка на фишку, я нахожу причину/код нуждающийся в модификации, хватаюсь за голову при виде кода и начинаю переписывать. Так были переписаны Альянсы, Друзья, система отправки флотов и многое-многое другое, включая кучу подсистем. Подробнее можно посмотреть в docs/changelog_dev.txt. Код - от "плохого" в начале этапа до "очень хорошего" в конце. В это же время я начал следовать phpBB Coding Standarts и подключил библиотеку темплейтов от phpBB3. Алгоритмы этого этапа примерно 50 на 50 - половина следует за оригиналом, половина переписывается с нуля.
4. Этап "паблик" (октябрь 2010 - декабрь 2010). Несколько инсталляций и отзывов заставили переработать подсистемы статистики и апдейтера, а так же проработать документацию для сторонних пользователей. Так же отзывы показали, что от унаследованного кода нужно избавлятся полностью. Полурабочие системы регистрации и входа в игру, нерабочая система восстановления паролей, нерабочая очередь построек (отключенная на моих серверах, но включаемая в настройках) и множество других косяков - то, на что я и игроки моих вселенных уже не обращали внимание. Так же обнаружилось несколько неприятных багов, о которых игроки моих серверов не сообщали ни разу. Обнаружилась нестойкость движка к подмене данных на стороне клиента - изначально в RR так же полностью отсутствовала проверка корректности получаемых данных, а сам я очень жестко банил на сервере хакеров и проблема остро не вставала... до начала эксплуатации в других условиях. Заодно стало понятно, что код предыдущих этапов надо переписывать по той же причине. Начал перетрушивать файловую организацию движка. Чем больше файлов - тем медленнее работает сервер. На моем сервере это незаметно, но на слабеньких компьютерах, на shared хостингах и просто на плохо настроенных машинах полезли проблемы. Код от "средненького" до "очень хорошего". Почти всё, переписанное или написанное на этом этапе использует мои собственные алгоритмы (там, где это имеет смысл). Остальные алгоритмы либо элементарные, либо модифицированы для увеличения скорости работы.
5. Этап "оптимизации" (январь 2011 - январь 2012). Нагрузочное тестирование на одном из серверов продемонстрировало полную несостоятельность самой критичной части движка - менеджера летящих флотов - и подтвердило мнение о необходимости полностью избавлятся от унаследованного кода, меняя алгоритмы работы.
6. Этап "MVC" (начиная с февраля 2012 года). MVC ака Model-Controller-View - концепция разделения кода по функционалу. Подробнее - http://ru.wikipedia.org/wiki/Model-View-Controller . MVC кажется избыточной, но для сложных проектов она очень сильно облегчает создание модульных приложений.
   В районе нового 2012 года я проводил различные эксперименты по использованию сторонних MVC-фреймворков. Увы, результаты оказались крайне плачевными. Проблемы в изначальной архитектуре xnova даже с учетом моих исправлений (а иногда, увы, благодаря им) не давало шансов на использование существующего кода. Вывод однозначен - для использования сторонних фреймворков надо переписывать полностью ВСЁ. Это потребует несколько горлумомесяцев и в текущих условиях невозможно. Поэтому я принял следующее решение - постепенно довести архитектуру СуперНовы до MVC-подобной и лишь затем начинать миграцию. Текущий этап посвящен именно этому. Он разбит на несколько подэтапов:
   1. Избавление от кода, написанного на 1, 2 и частично 3 этапах. Это так называемый "xnova-код" или попросту "говнокод". Собственно по косвенным данным GIT и моим прикидкам, собственно кода xnova осталось где-то процентов 10-15, если считать темплейты. Если не считать - не более 5%. Однако количества говнокода существенно больше. Я сам активно плодил его на 1-3 этапах. Плохое знание PHP и короткое знакомство с его возможностями, слабое знание исходников xnova, слабое понимание перспектив движка, следование изначальной архитектуре - вот причины выхода говнокода из моих рук.
   2. Избавление от кода, написанного с середины 3-го и по 5й этапы включительно. Это так называемый "PTL-код". Большой шаг вперед по сравнению с говнокодом! Я набрался опыта в PHP, ознакомился с его возможностями и самое главное - выработал стратегию развития СуперНовы. Стратегия - понятно, еще не архитектура, но уже значительный шаг вперед. Напрямую используется phpBB Template Libriary. В этой парадигме рендерер движка оперирует объектами-темплейтами, а не строками, как xnova-движок. Почти весь текущий код основной части движка является PTL-кодом. По сути своей это т.н. spaghetti-код в легкой разновидности: смесь реакций на действия, изменений данных, рендеринга темплейта - и все это густо приправлено MySQL-кодом без малейшего намека на абстракцию. Конечно, бывает еще хуже - как, например, в говнокоде, где представление (HTML-код) не было отделено от данных. Сейчас движок находится именно на этом подэтапе. Начиная с версии 35a12.0 я вплотную занялся рефакторингом кода и переписыванием явных фрагментов говнокода. Например, в настоящий момент (сентябрь 2012) я избавляюсь от использований переменной $parse и связанной с ней кода. Заодно это так же влечет полное переписывание отдельных страниц и целых подсистем. Так, в частнсти, были переписаны страницы Заметок и Технологий. А так же многие другие.
   3. Рефакторинг кода под концепцию MVC. Часть работы проделана уже сейчас. Например, модуль player_race уже является по факту MVC. Особенности разработки движка (восходящий метод) привели к существованию нескольких подтипов MVC-кода:
      • preMVC - это страницы, которые используют механизм MVCv1 (см. ниже), но не являются классами. Например, страница чата (/includes/pages/chat.php, да и все остальные в этом каталоге)
      • MVCv1 - это код, который использует текущие возможности MVC-модели. Например, модуль player_race (см. массив 'mvc' в манифесте). Большая часть этих возможностей заточена на создание модулей и пока слабо приспособлена для обработки отдельных страниц. Поэтому сейчас я разрабатываю следующую более универсальню версию MVC-подобной архитектуры MVCv2.
      • MVCv2 существует пока только в виде архитектуры в моей голове. Предполагается, что это будет совсем MVC и вообще 42. Посмотрим.

В движке СН (как и в любом программном продукте) есть баги. Я стараюсь тщательно тестировать все обновления, однако наличие говнокода и его взаимодействие с нормальным кодом вносит свои коррективы.

Не стоит путать "баги" с "особенностями". Я с самого начала открещивался от оффа. Копировать чужое мне неинтересно. Кроме того, отдельные аспекты оффа вызывали недоумения, вопросы и лично мне портили удовольстви от игры. Я завязал играть на оффе, когда выяснил, что вышедшего из нуб-зоны игрока может атаковать топ-1. Естественно, у меня защита новых и слабых игроков реализована иначе - по примеру XNova.

Я меняю те части игры, которые не нравятся лично мне, на те, которые мне нравятся. Т.е. я делаю игру, в которую лично мне интересно играть. Все пожелания и предложения рассматриваются именно в таком ключе - будет ли мне интересно играть в игру с такими изменениями? Например, мне (за небольшим исключением) нравится текущая система расчета боя. Система оГейма мне кажется крайне нелогичной, неинтуитивной и неинтересной. Поэтому я буду доделывать свою систему, а не ориентироваться на офф.

Вообще, статус проекта, как такового - "Альфа". Это значит, что отдельные аспекты игры в ходе разработки могут быть полностью изменены. Планы изменений есть в исходниках - желающие могут с ними ознакомиться.

Стандарты кодирования (Coding Guidelines)

Начиная с августа 2010 года, я стараюсь следовать phpBB3 Coding Guidelines (далее - PCG) с одним исключением: табуляция расширяются в два пробела и заменяются по возможности на пробелы. Выделяются два уровня совместимости: PCG или PCG0 - код отформатирован в соответствии с PCG; PCG1 - включает PCG0, а так же означает, что переменные названы в соответствии с PCG и правильно расставлены одинарные и двойные кавычки

Модули, подсистемы и префиксы

Предопределенные функции и пакеты

Идентификаторы широко используются в названиях файлов, функций, переменных и так далее для облегчения навигации в коде

Версионирование

СуперНова состоит из двух взаимосвязанных компонентов: базы данных MySQL и PHP-движка. Версионирование каждого из компонентов осуществляется отдельно.

В БД СуперНовы в таблце config в записи с ключом `config_name` = 'db_version' хранится её текущая версия. Версия БД - число, которое увеличивается каждый раз при изменении структуры БД.

Версия движка СуперНовы хранится в файле /includes/constants.php в константе SN_VERSION. Номер релиза хранится в том же файле в константе SN_RELEASE. Движок версионируются строкой <release><stage>[<edition>][r<revision>], где

• <release> - релиз СуперНовы. Увеличивается при одноразовом значительном изменении в коде движка (новая фишка, переписывание целой подсистемы итд), при накоплении большого числа мелких правок или при изменении версии БД.
• <stage> - этап текущей версии. Строчная буква английского алфавита, увеличивающаяся при переходе на следующий этап работы над движком. Может принимать следующие значения:
  • a - "alpha" - предварительная "скелетная" версия. На публике появляется в качестве "proof of conception" и используется для оценки востребованности изменения, предварительной демонстрации возможностей, поиска грубых ошибок в логике работы итд. Обычно не уходит дальше тестового сервера. Крайне нежелательно устанавливать куда-либо кроме сервера, предназначенного специально для тестирования
  • b - "beta" - версия для открытого тестирования. Рекомендуется для установки тем, кто хочет пораньше ознакомиться с новыми фишками и желает помочь в отлове багов. Качество таких версий может колебаться от "чуть лучше альфы" до "почти релиз". Желательно ставить на отдельную тестовую вселенную, которой не страшны вайпы
  • c - "candidate" - пре-релиз. Версия, в которой устранены все известные ошибки и вылизан интерфейс. Установка такой версии на production сервер относительно безопасна и очень желательна для поиска особо хитрых багов, проявляющихся только под большими нагрузками или в особых условиях
  • d - "deployment" - стабильная версия для развертывания на production серверах, релиз
  • e - "extra" - пост-релиз с небольшими изменениями. Это может быть обновленный дамп БД, изменения в документации, поправки в локализации, тюнинг интерфейса, а так же косметические багфиксы. Устанавливать этот релиз необязательно
  • f - "fixes" - пост-релиз с фиксами внезапно обнаруженных в релизе критических багов или проблем с внутриигровым балансом. Объема добавленного кода недостаточно для выпуска следующего полноценного релиза, однако апгрейд до этой версии крайне рекомендуется
• <edition> - редакция очередного этапа текущей версии. Необязательный параметр. Изменяется при необходимости отметить модификацию кода на текущем этапе
• r<revision> - ревизия движка. Необязательный параметр. Изменяется автоматически системой контроля версии. Добавляется, когда необходимо различать редакции СуперНовы в процессе разработки

В движке вместе с номером его версиии хранится так же требуемая версия БД (константа DB_VERSION в /includes/constants.php). Если движок запустится на версии БД выше, чем та, с которой может работать, он аварийно прекратит свою работу с сообщением об ошибке. В нормальных условиях такого произойти не должно. Такое может произойти, например, при восстановлении бэкапа более новой версии БД на старый движок. Данный механизм призван блокировать возможные повреждения структуры БД в случае ошибок администратора сервера, сбоев в скрипте резервирования/восстановления, хакерской атаки итд.

В движок встроен автоапдейтер структуры БД. Поэтому если более новая версия движка будет запущена на старой версии БД, он автоматически производет необходимые изменения в структуре базы (включая все необходимые перерасчеты). Поэтому в случае необходимости можно восстанавливать старые бэкапы БД на новую версию движка.

Коммиты в GIT

Начиная с версии 26 описание коммитов в GIT-репозиториях стандартизировано. Они имеют следующий формат:
<type>-<subsystem_affected>[-version]: <comment>

Начиная с ревизии 34a8.1 описание коммитов в GIT-репозиториях изменилось. Теперь они имеют следующий формат:
<subsystem_affected>-<type>-version: <comment>
Обращаю внимание, что параметр version стал обязательным и контролируется git-хуком

Расшифровка переменных:

• type - тип коммита. Может принимать следующие значения:
  • release - релиз движка. В комментарии указывается тэг, по которому можно получить данный релиз
  • crit - устранена критическая ошибка в коде или уязвимость. Необходимо срочно установить это обновление
  • fix - устранена ошибка в коде. Крайне желательно установить это обновление
  • feat - обновление добавляет новую небольшую фичу в движок (большая фича меняет номер версии). Можно поставить это обновление, можно дождаться очередного релиза
  • misc - мелкое изменение, не влияющее на игру. Например - изменение форматирования для соответствия PCG1, переименование переменных, небольшие изменения в алгоритмах и т.д.
  • doc - изменение в документации
  • work - промежуточный рабочий коммит. Обычно делается что бы зафиксировать работу над текущими изменениями в проекте, переключиться в другую ветку итд. Серия таких коммитов закрывается одним из вышеперечисленных типов.
  • git, а так же все коммиты без префиксов - технические коммиты, связанные с использованием GIT: внесение изменений в конфигурацию GIT, изменение тэгов, разделение/слияние веток итд
• subsystem_affected - список кодов подсистем, которые затрагивает этот коммит. Если их несколько, то ранее они разделялись знаком "+". Теперь упоминается только та подсистема, изменения в которой наиболее значительны
• version - версия движка
• comment - краткое описание коммита

Движок использует phpBB3 Tepmlate Engine (далее - PTE). PTE доработан до полной обратной совместимости со старым template-движком XNova, а так же для совместимости с моими новвоведениями. Из основных отличий можно отметить следующие:

• Доработанный PTE понимает название переменных из шаблона, написанные маленькими буквами
• Переменные вида L_xxx ("L" от "language") разворачиваются в переменную $lang['xxx']
• Переменные вида С_xxx ("C" от "config") разворачиваются в переменную конфигурации xxx ($config->xxx)
• Переменные вида D_xxx ("D" от "define") разворачиваются в константу xxx
• Поддерживаются индексированные значения переменных вида xxx[yyy]
• Символьные переменные не могут использоваться в условиях - их необходимо передавать в виде стандартных переменных PTL

Подробнее о формате темплейтов можно узнать в PCG и из документации phpBB3.

Шаблоны хранятся в каталоге /design/templates/<имя шаблона>. В настоящее время имеют расширение .TPL.HTML, а не .HTML, как в оригинальном PTE

СуперНова имеет встроенную систему логов для облегчения работы администрации сервера

Коды логов (таблица logs)