Come faccio a costruire qualcosa quando so che mi sbaglierò?

Question

Sfondo

Ho un progetto personale che ho cercato di costruire per circa 5 anni. In sostanza è un gioco online - un'applicazione web. Non è un "money maker", solo qualcosa che voglio davvero costruire, quindi è molto improbabile trovare i finanziamenti per assumere una squadra competente.

Ho costruito due prototipi pienamente funzionali nel corso degli anni, entrambi con successo da un punto di vista concept/utente, ma entrambi i fallimenti spettacolari da una prospettiva architettonica; il codice era un disastro, non poteva essere mantenuto o ulteriormente sviluppato, e doveva essere buttato fuori.

Ci sono voluti un paio di anni per acquisire le competenze necessarie per costruire il cliente - che è ricco/statico e piuttosto complesso. Ho allineato la mia carriera e gli studi verso questo lato del divario di sviluppo. Sono finalmente arrivato a un punto in cui posso costruire un cliente sofisticato, decentemente architettato, in grado di crescere e che non ha bisogno di essere buttato fuori 6 mesi prima. C'è un sacco di lavoro da fare su questo fronte, ma almeno so di poterlo fare, e lo faccio abbastanza bene. Il back-end è un'altra storia.

Finora ho ricostruito il back-end almeno 11 volte con varie combinazioni di PHP, SQL, Ruby, CouchDB, MongoDB, FriendlyORM, NodeJS ecc. Ecc. Di solito non arrivo molto lontano prima di scoprire qualche enorme difetto con il mio approccio e ricominciare: RPC to REST, relazionale al documento guidato. Sono ben consapevole che l'ottimizzazione prematura è la radice di tutti i mali, ma l'applicazione dipende molto da dati altamente dinamici e in rapido movimento. Progettazione, scaling, sharding, caching, auth, replicazione dell'API RESTful - Non ho molta esperienza con questo, e non posso aspettarmi di essere minimamente decente in qualunque momento presto. Queste cose richiedono anni di studio ed esperienza.

Ha più senso trovare un esperto in questo campo, ma senza finanziamenti sento che ho bisogno di distribuire con successo un altro prototipo per attirare la persona giusta. Quindi, dovrò solo costruirlo nel miglior modo possibile.

La questione

Supponendo che però io costruisco, l'architettura di back-end sta per essere sbagliato e dovrà essere ricostruita, qual è il modo migliore di procedere con la costruzione di "appena sufficiente" per continuare sviluppo dell'applicazione client? Anche se è brutto, c'è un modo per "mettere insieme" un servizio web JSON? Rubino con Sinatra e MongoDB? Django? Esiste un costruttore di servizi web out-the-box? Non c'è bisogno di un framework web a stack completo in quanto non esiste un livello di presentazione: solo dati. Qualsiasi consiglio sarebbe molto apprezzato.

Answer 1

La mia opinione: Troppa enfasi sulla tecnologia e non abbastanza per sedersi e fare i disegni giusti.

1. Inizia con un design di alto livello.
2. Identificare i diversi pezzi principali coinvolti. Trascorri un po 'di tempo di qualità per il passaggio n. & 2.
3. Scopri quali componenti possono essere utilizzati rapidamente per implementare rapidamente i diversi pezzi. Considera che in seguito potresti strappare questi componenti per qualcos'altro (inclusa la tua soluzione).
4. Revisit # 1 & # 2
5. Scegli un pezzo o due e inizia a codificare un prototipo funzionante per i pezzi coinvolti.
6. Dopo aver eseguito il legwork, ricominciare dal punto 1 e vedere cosa è cambiato in modo da poter compensare di conseguenza.

Answer 2

Non è necessario creare alcun tipo di back-end Web per poter procedere con la prototipazione dell'applicazione client. Basta fare in modo che le funzioni di stub della chiamata dell'applicazione client restituiscano dati fittizi.

Answer 3

Fatelo funzionare lentamente, prima con un codice pulito e modulare.

Se è modulare, è possibile sostituire uno o due livelli senza dover scartare il tutto.

Mentre forniscono la modularità, prestare attenzione ai servizi Web, anche REST, poiché tendono a essere lenti; c'è un sacco di spese generali con ogni connessione, per esempio.

Answer 4

Costruire un'applicazione complessa e di questo tipo, in particolare uno con un sacco di interdipendenze, condizioni specifiche dello stato e divisioni client-server che potrebbero richiedere l'uso di lingue incompatibili, è scoraggiante, non importa come ci si avvicina. Sulla base della mia esperienza con altri progetti di questo tipo, sei destinato a fallire al primo tentativo, non importa quanto tu sia attento. Il trucco è quello di abbracciare il fallimento come un passo inevitabile lungo la strada verso il successo e non agitarsi su ogni piccola cosa mentre costruisci l'applicazione.

La prima missione dovrebbe essere quella di farlo funzionare "con la minore programmazione possibile, per ottenere semplicemente l'effetto che si sta cercando, anche se molto approssimativamente, in modo da poter vedere come tutto si combina perfettamente. Se riesci a scomporre il grande problema in una serie di problemi più piccoli da risolvere, potresti trovare successo con un elemento e ciò può essere motivo per affrontare problemi più grandi o diversi.

Una strategia utile da impiegare è quella di mantenere gli elementi dell'applicazione liberamente accoppiati, per evitare l'interdipendenza tranne laddove strettamente richiesto, in modo da poter scambiare o apportare miglioramenti a porzioni del tutto senza una cascata di modifiche consequenziali. Ad esempio, il tuo codice di rete potrebbe essere in grado di trasmettere cambiamenti di stato tra client e server senza preoccuparsi della natura degli stati stessi, ma il tuo codice di gestione dello stato non dovrebbe preoccuparsi di come vengono trasmessi gli stati, solo che lo saranno.

È anche utile avere un controllo sull'architettura generale dell'applicazione in modo da non perdersi tra le erbacce. Da una prospettiva di alto livello, potresti voler avere familiarità con lo standard Design Patterns che può aiutarti a organizzare un pasticcio di codice altrimenti impenetrabile in qualcosa di semplice, modulare e facile da compilare.

In materia di framework e lingue, direi evitare di cambiare così spesso. Mentre è educativo esplorare un nuovo linguaggio per vedere quali caratteristiche possono aiutare con il tuo particolare problema, sarai probabilmente più produttivo se ti affidi a uno, anche se può essere difficile ottenere alcune cose, perché diventi più efficace con esso , migliorando il tuo approccio per adattarsi meglio alla lingua. Mentre Haskell potrebbe essere più adatto ad alcuni problemi, anche il semplice vecchio PHP può essere istruito a fare esattamente le stesse cose con sufficiente determinazione.

C'è la tentazione di provare cose nuove, di ampliare lo scopo del lavoro per averlo "fatto bene", per costruire nuove funzionalità come ti viene in mente, ma per mantenere il progetto sotto controllo avrai mantenere la disciplina per evitare queste attività costose e distrattive che sono spesso, prese oggettivamente, solo voli di fantasia o premature dato lo stato generale del progetto.

Per rispondere in modo specifico alla tua domanda, costruiscila nel framework con cui hai più familiarità, dove sono i tuoi punti di forza e fallo con incrementi più piccoli che producono risultati utili.Forse è il motore di visualizzazione del client, o il componente di rete, o le transizioni dello stato back-end, ma qualunque cosa sia, dovresti averlo in uno stato "abbastanza buono" per iniziare ad associare altri componenti ad esso.

Risolvere dieci piccoli problemi può essere noioso e richiede molto tempo, ma è molto più semplice che risolverne uno gigantesco.

Answer 5

Johnny G praticamente lo ha inchiodato con il suo commento alla tua domanda originale. La situazione che descrivi succede anche alla fortuna 500 ci crediate o no. È necessario pianificare attentamente ciò che si sta cercando di costruire/realizzare con il proprio progetto prima di scegliere e lanciare le tecnologie più nuove e più interessanti ogni tre mesi.

Penso che questo articolo da cablato, "impara a lasciare andare" sul fallimento di Duke nukem per sempre a finire per essere spedito, spiegherà questo meglio di me.

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

(è anche un bel divertimento/informativo letta a prescindere)

Answer 6

Se il progetto fa schifo e nessuno ha mai lo usa, che cosa ci importa quanto sia ottimizzato? Ottenere una versione end-to-end funzionante, sono sicuro che scoprirete molti altri problemi che non avete ancora considerato, che sono probabilmente di maggiore importanza.

Answer 7

Trovo che ci sia solo un modo per completare un progetto personale.

Codice smart prima, piano dopo. Sviluppa quel prototipo, ma disegnalo in modo che ogni singolo pezzo possa essere rimosso e sostituito da un altro pezzo.

Se la lingua scelta è rubino, ad esempio, è possibile creare classi con un'interfaccia ben definita che non si interromperà mai. Preoccupati per ogni funzione che "fa" la cosa giusta, senza preoccuparsi di come funziona.

Quindi, torna al tuo prototipo costruito in modo modulare e fissa un pezzo alla volta.