Создание такого крупного и сложного приложения такого типа, особенно такого, которое имеет множество взаимозависимостей, состояний, специфичных для состояния, и разделений клиент-сервер, для которых может потребоваться использование несовместимых языков, является сложной задачей, независимо от того, как вы к ней подходите. Исходя из моего опыта работы с другими подобными проектами, вам суждено провалиться с первой попытки, независимо от того, насколько вы осторожны. Хитрость заключается в том, чтобы воспринимать неудачу как неизбежный шаг на пути к успеху, а не суетиться над каждой мелочью при создании приложения.
Первая миссия должна состоять в том, чтобы заставить его «работать» с как можно меньшим количеством программирования, чтобы просто получить эффект, который вы ищете, даже если очень грубо, чтобы вы могли видеть, как все это сочетается. Если вы можете разбить большую проблему на ряд более мелких проблем, которые вы хотите решить, вы можете добиться успеха с одним элементом, и это может быть мотивом для решения больших или разных проблем.
Полезная стратегия, которую следует использовать, заключается в том, чтобы элементы приложения были слабо связаны, чтобы избежать взаимозависимости, за исключением случаев, когда это строго требуется, чтобы вы могли менять или улучшать части целого, не имея каскада последовательных изменений. Например, ваш сетевой код может передавать изменения состояния между клиентом и сервером, не заботясь о природе самих состояний, но ваш код управления состояниями не должен заботиться о том, как передаются состояния, только о том, что они будут.
Также полезно иметь представление об общей архитектуре приложения, чтобы не потеряться в сорняках. С точки зрения высокого уровня, вы, возможно, захотите ознакомиться с базовыми шаблонами проектирования , которые могут помочь вам превратить непонятный беспорядок кода во что-то простое, модульное и простое для сборки.
Что касается фреймворков и языков, я бы сказал, избегайте частого переключения. Изучая новый язык, чтобы узнать, какие функции могут помочь в решении вашей конкретной проблемы, вы, вероятно, будете более продуктивны, если будете придерживаться одной из них, даже если вам будет трудно достичь некоторых целей, потому что вы становитесь более эффективными с этим , улучшая ваш подход, чтобы лучше соответствовать языку. Хотя Haskell может лучше подходить для некоторых проблем, даже старый добрый PHP можно научить делать точно такие же вещи с достаточной решимостью.
Существует соблазн пробовать что-то новое, расширять объем работы, чтобы она была "сделана правильно", создавать новые функциональные возможности, как вам кажется, но чтобы держать проект под контролем, вам придется соблюдайте дисциплину, чтобы избежать этих дорогостоящих и отвлекающих действий, которые часто, объективно воспринимаются только как причудливые или преждевременные полеты, учитывая общее состояние проекта.
Чтобы конкретно ответить на ваш вопрос, создайте его в структуре, с которой вы наиболее знакомы, где ваши сильные стороны, и делайте это с меньшими приращениями, чтобы получить полезные результаты. Может быть, это механизм отображения клиента, или сетевой компонент, или внутренние переходы состояний, но что бы это ни было, вы должны иметь его в «достаточно хорошем» состоянии, чтобы начать присоединять к нему другие компоненты.
Решение десяти небольших проблем может быть утомительным и занимать много времени, но это гораздо проще, чем решить одну гигантскую.