Как я создаю что-то, когда я буду знать, что пойму его превратно?

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

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

Я думаю, что эта статья от Wired, «научись отпускать» о том, что Duke Nukem навсегда не удалось в конечном итоге получить, объяснит это лучше, чем я.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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