Организация разработки крупного проекта через API

Доброго времени суток.
Есть проект браузерная онлайн игра которая разрабатывается уже какое-то время, только мной. То есть я единственный у кого есть доступ к php скриптам.

Из за того, что я работаю один в целом проект развивается очень медленно.
И вроде есть деньги нанять еще 2-3 php-программиста, но проблема в том, что за время разработки на мой взгляд проект накопил достаточно много ценной информации которую просто так не даш в свободный доступ. Попросту я боюсь, что нанимая новых программистов кто-то из них обязательно унесет с собой части проекта или того хуже создаст копию, что-то на подобие онлайн игр: комбатса(BK) и олдкомбатса(oldBK).

У меня возникла такая идея, не давать новому программисту доступ к самому проекту, а дать доступ к API проекта, что-то на подобие API ВКонтакте.

Например в проекте есть следующие модули:
/base
/chat
/shop
/battle

Предположим, что у нас есть три программиста каждый работает только над своим модулем:
/base - Общяя папка для всех программстов
/chat - Программист #1 работает над чатом
/shop - Программист #2 работает над магазином
/battle - Программист #3 работает над боем

Соответственно программист #1 имеет доступ только к папкам /base и /chat
Соответственно программист #2 имеет доступ только к папкам /base и /shop
ну и т.д.


Но вот, что если программисту #3 нужна функция для работы с чатом, например:
Программист #3 написал функцию задача которой по завершению боя написать в чате сколько пользователь получил опыта.

Для подобной реализации программсту #3 нужен класс для отправки сообщений в чат. Но к этому классу у него нет доступа. А как я уже сказал дать такой доступ я не могу.

Какую я предлагаю реализацию.
Для получения подобного метода(отправки сообщений в чат) программист #3 просит меня или напрямую обращается к программисту #1 с просьбой сделать данный метод доступным через chat.api, а дальше один в один как API ВКонтакте. Программисту #3 для отправки сообщений в чат достаточно будет выполнить что-то вроде такого:
file_get_contents('http://chat[dot]api[dot]game[dot]ru/?method=[dot][dot][dot]sage&msg=Бой закончен, Вы получили 5 опыта.');


Идея вроде очень хорошая, она полностью решает проблему с тем, что твой проект кто-то украдет так как у каждого программиста будет только та часть кода над которой он действительно работает.

Но здесь есть один минус, это медленный http протокол с которым теперь будет взаимодействовать api.

Какие еще существуют подобные способы организации api кроме http протокола?

Какие вообще варианты разработок крупных проектов существуют?

Например, как устроена организация разработки того же контакта или фейсбука?

Почитайте, что такое интерфейсы и абстрактные класы.
лично Я вижу это таким образом. например:

-----
просто ?: сложно

ну да, попутно каждый из них должен будет выполнить кучу!!! работы, причем ненужной по созданию затычек для этих классов. в итоге производительность сильно не увеличится, а вот траты на их время существенно, а иначе никто не захочет вот так тратить время.

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

-----
просто ?: сложно

С крупными проектами работа обычно уже налажена.
Открывают твою ветку исходников, настраиваешь NetBeans на работу с репозиториями, где тебе уже открыто то что нужно и пользуешься.
Обычно если проекты крупные, то приняты строгие стандарты по стилю и комментариям, потому разобраться не сложно. Душа радуется, когда откроешь любой класс и видишь комментарии перед объявлением всех открытых методов, что они получают, что возвращают.
Если что-то не понятно, на этот случай есть руководитель проекта которого ты можешь в любой момент дернуть по скайпу и расскажет что нужно, откроет доступ к нужным веткам или расскажет для чего нужны те или иные интерфейсы если сам не вкурил и нет возможности спросить того кто писал код.
Тостеры, когда в конце дня проверяют что ты накодил, отписывают найденные баги и проблемы в багтрекер, рук-ль кидает баги на того разработчика который занимается этим модулем.

еще один параноик
то что твой доморощеный проект "накопил" уже давным давно накоплено в тысячах проектов лежащих в инете в свободном доступе.

тебе еще надо будет вложить кучу бабла чтобы твой проект вообще кто нибудь заметил

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Хочу сразу пояснить несколько моментов.
Проекту уже более двух лет.
Каждый день в игре онлайн от 1200 до 1600 пользователей.
То есть проект уже какое-то время стабильно работает на рынке.

Мой вопрос был в основном направлен исключительно на новую идею организации разработки через HTTP API. Насколько это хорошо или плохо?

Главное условие чтобы новый программист не имел доступа к другим модулям проектам.

P.S. Конечно, если я буду реализовывать подобный подход через API, то я и все остальные программисты будем подробно все документировать для вновь прибывших программистов.
(Добавление)

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

(Отредактировано автором: 09 Октября, 2012 - 13:10:58)

Zuldek а можно подробней про доступ к веткам, какие возможны ограничения, и какой именно SVN сервер используется?

и как тут поможет svn?

хочешь прятать исходники пиши на яве а не на на PHP

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Да конечно я использую SVN, но он здесь совершенно не причем, если я могу закачать и выполнить php файл на сервере к которому даже автоматически инклудется какой-то другой файл, то я могу получить исходный код этого файла.

Это и есть основная проблема.

Мне в основном доводилось работать с svnserve и Subversion соответственно. Хотя принципы у всех одинаковые.
В последних версиях количество разграничений и настроек там много (разумеется, не просто права на директории).
Ветки это моя фривольная интерпретация дерева файлов модуля проекта к исходникам которого открывают доступ.

проблемма как я уже намекал исключительно у тебя в голове.

С возрастом и опытом это пройдет.

По молодости я тоже думал что мои проекты всем интересны. Потом оказалось что надо еще нехило заплатить человеку чтобы он согласился ковырятся в твоем коде и дорабатывать его.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

А зачем разработчику давать возможность загружать модули на боевой сервер? Они пишутся таким образом чтобы их можно было протестировать как модуль, независимо от основного проекта, иначе это уже его неправильная организация изначально.

Если у вас идут инклуды подобного: include somethingwithoutmygamedoesnotwor k.php
Содержащие основную массу всех классов движка то это уже неправильная организация.
Обычно идет подключение базовых классов (инструментарий для работы с моделями и т.д.)
И открытых интерфейсов через которые общаемся с другими модулями.
Соответственно для успешного тестирования модуля в этом случае необходимо просто передать ему то что будут передавать модули с ним взаимодействующие и проверить возвращаемые результаты. Все.
Там на пушечный выстрел к боевому серверу не подпускают. Провел тестирование - обновил репозитории. Ведущий разработчик или тостер, как там у кого принято, уже смотрят как работает мое творчество на боевом. Во всяком случае так было в командных проектах с которыми доводилось работать. Сейчас проекты маленького калибра, где даже в SVN нет большой необходимости (ибо 1-3 разработчика задействованы).

Ну ещё, если уже совсем все печально, можете потребовать подписать соглашение о неразглашении и прочие подобные бумажки ваших наймитов будущих

(Отредактировано автором: 09 Октября, 2012 - 13:44:19)

Я прошу вас очень вежливо не обращаться ко мне в таком тоне.

Еще раз хочу пояснить суть темы: