Как мне создать что-то, когда я знаю, что я ошибаюсь?

Фон

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

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

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

До сих пор я перестраивал back-end по крайней мере 11 раз с различными комбинациями PHP, SQL, Ruby, CouchDB, MongoDB, FriendlyORM, NodeJS и т.д. и т.д. Я, как правило, не очень далеко, прежде чем обнаруживаю огромные недостаток с моим подходом и начало: RPC to REST, реляционный к документированному. Я хорошо знаю, что преждевременная оптимизация - это корень всего зла, но приложение сильно зависит от быстро движущихся высокодинамичных данных. RESTful API-дизайн, масштабирование, окантовка, кеширование, аутентификация, репликация. У меня нет большого опыта в этом, и я не могу рассчитывать на то, что в ближайшее время будет достаточно прилично. Эти вещи требуют многолетнего изучения и опыта.

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

Вопрос

Предполагая, что, тем не менее, я построю его, внутренняя архитектура будет неправильной, и ее нужно будет перестроить, что лучший способ продолжить строительство "достаточно" для продолжения разработки клиентского приложения? Даже если это противно, есть ли способ "бросить" веб-сервис JSON? Ruby с Sinatra и MongoDB? Django? Есть ли какой-то встроенный webservice builder? Нет необходимости в веб-инфраструктуре полного стека, поскольку нет уровня представления - просто данные. Любые советы были бы с благодарностью.

Ответ 1

Мое мнение: слишком много внимания уделяется технологии и недостаточно для сидения и выполнения правильных проектов.

Начните с дизайна высокого уровня.
Определите различные основные части. Проведите некоторое время для шага №1 и 2.
Посмотрите, какие готовые компоненты вы можете использовать, чтобы быстро реализовать различные части. Подумайте, что позже вы можете удалить эти компоненты для чего-то еще (включая собственное решение).
Revisit # 1 и # 2
Выберите часть или две и начните кодирование рабочего прототипа для задействованных частей.
После того, как вы закончили работу, начните с шага №1 и посмотрите, что изменилось, чтобы вы могли соответственно компенсировать.

Ответ 2

Заставьте его работать медленно, во-первых, с чистым модульным кодом.

Если он модульный, вы можете заменить слой или два, не откладывая все это.

Пока они обеспечивают модульность, будьте осторожны с веб-сервисами, даже REST, поскольку они, как правило, медленны; есть много накладных расходов с каждым соединением, например.

Ответ 3

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

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

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

Также полезно иметь дескриптор общей архитектуры приложения, чтобы вы не потерялись в сорняках. С точки зрения высокого уровня вы можете быть знакомы с базовыми Design Patterns, которые могут помочь вам организовать непрозрачный беспорядок кода во что-то простой, модульный и простой в использовании.

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

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

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

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

Ответ 4

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

Ответ 5

Джонни G довольно много прибил его своим комментарием к вашему оригинальному вопросу. Ситуация, которую вы описываете, даже случается с удачей 500, верьте этому или нет. Вам нужно точно планировать, что именно вы пытаетесь построить/выполнить с вашим проектом, прежде чем выбирать и выбрасывать новейшие и самые крутые технологии каждые три месяца.

Я думаю, что эта статья из проводной, "научись отпускать" насчет провала герцога нукема навсегда, чтобы попасть в нее, объяснит это лучше, чем я могу.

http://www.wired.com/magazine/2009/12/fail_duke_nukem/

(это также довольно забавное/информативное чтение независимо)

Ответ 6

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

Ответ 7

Я нахожу там только один способ завершить личный проект.

Сначала введите код smart, затем заплатите. Разработайте этот прототип, но сконструируйте его так, чтобы любой отдельный кусок можно было удалить и заменить другим.

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

Затем вернитесь к прототипу, построенному модульно, и закрепите по одному фрагменту за раз.