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

Question

фон

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

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

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

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

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

Вопрос

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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