Определите интерфейс и четко разделите ответственность

Как и в большинстве веб-проектов, у вашего есть четко разделенные интерфейс и серверная часть (вероятно, еще больше после переписывания интерфейса) со специальным интерфейсом между ними. Объясните, что вы готовы предоставить ему интерфейс, о котором он просит (REST API), но что внутренний код — любая его часть — запрещен. Вместе разработайте функциональность этого интерфейса, но относитесь к коду, который подключается к нему, как к черному ящику — с обеих сторон.

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

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

Этот подход служит трем целям:

1. Это должно помочь вам работать вместе более эффективно, четко определяя обязанности и ожидания. Всякий раз, когда он поднимает детали реализации на бэкэнде, укажите, что это не входит в сферу вашего обсуждения.
2. Вы можете использовать его в качестве основы для обсуждения общих проблем, таких как игровой процесс.
3. Если вы в конечном итоге пойдете разными путями (и он заберет свой код с собой) или через несколько лет вы заметите, что ваш технический стек действительно недостаточно хорошо масштабируется, вы остаетесь с отдельными функциональными кодовыми базами и можете заменять части по мере необходимости. нужный. О чем вы можете беспокоиться , когда это действительно станет проблемой, вместо того, чтобы тратить время на споры об этом сейчас.

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

Судя по всему, ваш коллега-разработчик будет непоколебим в своем мнении о вашем подходе. Чем больше вы оба будете работать над этой игрой, тем больше он будет спорить. Это также означает, что он не представил никаких убедительных причин для внесения широкомасштабных изменений, которых он требует.

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

Пара вещей. Прежде всего: это хобби-проект. Ваш хобби-проект. Другой разработчик был привлечен, чтобы помочь вам с веб-сайтом. Может быть, мне не хватает какой-то информации, но почему он думает, что имеет право голоса в том, что вы делаете со своим проектом? Скорее всего, вы находитесь в процессе обучения, наслаждаясь тем, что вам нравится делать в свободное время (при условии, что вы ходите в школу/работаете). Вы уже потратили 9 месяцев на проект, готовы ли вы выбросить все это в мусорное ведро, перенеся на другие языки, а не разрабатывать новые функции или улучшать вещи? Его предложения намекают на масштабируемость. Я не думаю, что это применимо к такому хобби-проекту, как этот, если вы действительно не планируете достичь большой пользовательской базы.

Возвращаясь к вашему вопросу, видя, что он хочет изменить многие принятые решения, лучше (на мой взгляд) отпустить его и двигаться дальше в одиночку. Он помог вам с веб-сайтом в соответствии с вашей просьбой (и, согласно вашей истории, у него не было другой роли), и вы довольны его работой. Это нормально, чтобы оставить это на этом.

Кроме того, в отличие от того, что предложил БобоДарф в своем ответе, я бы не позволил ему разветвить вашу работу. Опять же, это мое мнение, но этот проект довольно частный и стоил вам много часов (не говоря уже о возможных головных болях). Готовы ли вы позволить другим работать бесплатно со всем, ради чего вы много работали (читай: игра в текущем состоянии)?

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

Вы, конечно, должны оставаться в дружеских отношениях, и вы можете привести причины, если хотите (например, ваши подходы к техническим стекам, которые вы хотите использовать, слишком разные), но не идите на компромисс. Если это открытый исходный код, вы можете побудить его разветвить его и внести изменения, которые он хочет, до его собственного облика.

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

У меня есть достаточный опыт в подобном свете — большую часть десятилетия я был ведущим разработчиком нишевого, но, по крайней мере, умеренно успешного проекта с открытым исходным кодом. Теперь мы регулярно получаем предложения о помощи в разработке — возможно, пару раз в месяц. В среднем у нас, вероятно, был примерно один полезный человек в год — остальные были отвергнуты в той или иной форме. Обычный подход, который мы используем, когда мы получаем кого-то, кто кажется заинтересованным, заключается в следующем:

• У нас есть абзац с копией/вставкой о том, как они могут отправить запрос на вытягивание, но мы не обязаны принимать его, они не должны предполагать, что мы это сделаем, если это что-то, против чего нет тикета, тогда это маловероятно, что он вообще будет принят, код подчиняется этим правилам качества и т. д. Примерно в половине случаев после этого мы ничего не слышим.

• Всякий раз, когда кто-то предлагает серьезное изменение (изменение фреймворка, существенную реструктуризацию кода и т. д.), у нас появляется еще один абзац копирования/вставки с благодарностью за их предложение и сообщением, что мы рассмотрим его в течение следующих нескольких месяцев, но мы победили. не принимайте PR за такие изменения. В любом случае, у нас был по крайней мере один парень, который пытался один раз.

• Почти никто не получает доступ к фиксации. Все остальные участники работают через PR, которые проходят проверку кода, и последнее слово остается за одним из трех постоянных разработчиков (обычно, если они не уверены, что мы примем решение вместе). Решение является окончательным.

Мы кого-то обидели таким образом, или избавились от полезных контрибьюторов/вкладов? Почти наверняка. Но это проект-хобби, поэтому я предпочитаю не увязнуть в придуманных мною дебатах и ​​бюрократии. Если вам нравится взаимодействовать с людьми таким образом и вести эти долгие дебаты о том, лучше ли их идея/подход, и стоит ли переписывать всю систему с нуля, то, во что бы то ни стало, дерзайте. Но если нет, то и не позволяйте себе в это втянуться.

Если дело дойдет до драки (а судя по всему, так оно и есть), скажите своему помощнику, что она всегда может разветвить ваш проект, и тогда она сможет использовать все, что захочет, на бэкенде. В противном случае это ваш путь или шоссе. Кажется, люди думают, что разработка программного обеспечения с открытым исходным кодом — это демократия. Это не. Кто-то всегда должен будет сказать «используйте это, а не это» или «мы делаем это так, а не иначе». И на данный момент этим кем-то являетесь вы.

Если вы сосредоточитесь, а ваш «друг» или «товарищ по команде» должен создать большую и более вежливую хобби-игру (здесь сосредоточьтесь на хобби), давайте сосредоточимся на лучших функциях, а не на технологиях: что лучше для ваших игроков? Исправлять ошибки/добавлять новые функции или менять технологии?

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

Примечание: если кто-то пытается вам помочь, сначала выслушайте. Судя по вашим вопросам, похоже, после этапа листинга и уже на "защитной" стороне коммуникаций, означает, что вы уже решили не переключать технологии и ничего не менять. Каковы причины для изменения стека?