Вопрос организации кода в родственных проектах.

#организация_кода #git #пет-проекты #нашкодили

Есть у меня пет-проект “Атлас”. Разумеется, репозиторий на гитхабе, комментарии в коде и все такое. Суть: можно на картах (векторных или растровых) размечать регионы, по которым задавать информацию. Ну, права доступа к контенту, всякое такое, CRUD, авторизация, etc.

В частности я применяю его для карты моей НРИ:

http://livemap.wintersky.ru/map/spring.confederation

Откроете информацию по звездной системе – увидите некий текст. Поля значимы – типы капитала, население, класс жизнепригодности, списки экспорта/импорта, список корпораций и так далее. Сейчас это все задается как просто plain/text в редакторе + кастомный шаблон. В шаблоне конечно что-то там прописано типа `id=summary-population`, но это костыль, неудобный для подсчета населения всей ойкумены.

Я задумался о форке этого проекта под индивидуальную задачу – атлас для конкретной игры. Соответственно на странице редактирования должна быть не просто форма с кучей полей для разных, нужных нам данных, нужна еще другая схема визуализации этих данных – и, разумеется, другая схема хранения этих данных в БД – JSON-ли объектом или просто больше столбцов в той же таблице. Или может быть отдельная таблица с кастомными столбцами?

Идея хранить в БД JSON-объект, который создается на основе сценария заполнения из редактора, поля которого построены на основе сценария заполнения, а потом выводятся на основе того же сценария пользователю мне кажется нерациональной (я потрачу кучу времени на решение, которое никто никогда кроме меня применять не будет).

Так я пришел к выводу о необходимости форка. Но есть подвох.

И форк, и основной проект совпадают по основной кодовой базе процентов на 90%. Действительно, вышеописанный атлас отличается от атласа, нужного большинству настольщиков ( http://livemap.wintersky.ru/map/winterland.westfjord  ), только:

  • другая схема данных в БД
  • другая страница редактирования (больше полей) + обработчик -> БД
  • визуализация данных ( <– БД)

…. на самом деле нет. Рано или поздно в форке дойдет дело до кастомного поиска по объектам, до “аналитики”, до вики-подобного синтаксиса в описаниях, до каталога звездных систем на отдельной странице и всякое такое.

Окей, не на 90% общая кодовая база, но на 75% уж точно: авторизация, парсинг SVG, фронтэнд-визуализация.

Но как быть дальше? Как обеспечить своевременную синхронизацию кодовой базы этих проектов, общей их части?

А) я написал что-то в основном движке – как эти вещи из ядра скопировать в ядро форка?
Б) а наоборот? Я пилю что-то в форке и вдруг понимаю, что эта фича крайне полезна и в основном движке. Как её туда перенести? Тупо копипастой? Это плохое решение, кмк.

Я дошел до двух вариантов:

1. Composer-package

Ядро движка делаем как пакет для композера, а потом подключаем его во все дочерние проекты (и основной livemap, и кастомный) через композер.

Есть проблема: композер – это только для PHP-кода (или я чего-то не знаю), систему визуализации (она на JS) или шаблоны (HTML) туда не добавишь (по крайней мере без костылей).

2. Parent for all

И основной движок “для всех” и кастомный являются форками некого базового репозитория.

Допиливаем что-то в форках базового репозитория  – PR в родителя, потом обновляем потомков.

Идея является развитием первой, но подводные камни я пока разглядеть не могу.


 

Какие еще варианты решения этой проблемы я упустил?

 

Отправить ответ

Добавить комментарий

  Подписаться  
Уведомление о