Come dividere e gestire i progetti

Ovviamente, ci sono molti modi per dividere un progetto in parti più gestibili, ma il modo in cui trovo sia facile che utile è strutturare il progetto attorno alle funzionalità che si intende implementare.

In primo luogo, definisci i tuoi casi d'uso e crea un elenco di funzionalità che prevedi di avere nel tuo prodotto. Dare quindi la priorità alle funzionalità che il prodotto deve avere per essere marginalmente utilizzabile. Una volta impostato questo set, puoi eseguire il refactoring delle cose che hai appreso sul dominio che ti sei perso prima di iniziare, o dare la priorità al prossimo set di funzionalità e aggiungerle.

Il vantaggio di questo approccio è che non è necessario decidere in anticipo sulla timeline contemporaneamente. Lo sviluppo di nuove cose è intrinsecamente imprevedibile, quindi tenere la timeline il più aperta possibile è una cosa gradita.

Ognuno organizza un progetto leggermente diverso, quindi sta a te decidere cosa funziona meglio per le tue esigenze. Ecco cosa faccio e spero che ti possa aiutare.

1. Scrivi ESATTAMENTE ciò che vuoi che il tuo progetto realizzi. Pensa ad esso come a un campo di partenza: definisci chiaramente gli obiettivi di questo progetto e come li realizzerai.
2. Disegna un carrello di flusso per il flusso di lavoro di base associato al tuo progetto. Come vuoi che l'utente interagisca con esso? Come funzioneranno le cose sul back-end? Quali possono essere alcuni trabocchetti comuni che dovrai cercare? Tutte queste cose dovrebbero essere chiaramente definite in un modo semplice da digerire.
3. Inizia in piccolo e fatti strada. Questo può sembrare un po 'ambiguo, quindi lasciatemi spiegare: Ovviamente, un progetto passa attraverso le iterazioni e "cresce" (sia nella maturità che nella complessità) nel tempo. Quindi, inizia con il caso di utilizzo minimo e inizia da lì. Ad esempio, sto sviluppando una piccola applicazione di messaggistica. Non mi addentrerò in un modello client / server in cui i client inviano messaggi al server. Invece, ho iniziato scrivendo semplici messaggi di testo in un file e avendo il programma analizzato quel file e stampando l'output corretto su STDOUT. Quando avrò finito quella parte, rifatterò quel codice per funzionare in un modello client / server. Adattare quel flusso di lavoro alle tue esigenze, ovviamente.
4. Solo una nota da tenere in fondo alla tua testa: finché il tuo progetto non raggiunge la "prontezza alla produzione", considera ogni carattere del codice spendibile. Se pensi a un modo "migliore" di fare le cose, fallo. Non mantenere il vecchio codice solo perché. Anche quando il tuo progetto raggiunge la produzione, non esitare a buttare via interi file se necessario. Il tuo codice può sempre essere migliorato. Sempre.

Battute a parte, è essenzialmente il modo in cui organizzo i miei progetti. Seguirò il flusso di lavoro di base, scriverò il codice per un caso d'uso di base, e poi procederò da lì, refactoring lungo la strada. Spero che ti aiuti!

A volte mi aiuta solo ... inizio. Dovunque io possa

Non dire che non dovresti progettare; ovviamente ogni progetto ha bisogno di un design, e un grande progetto probabilmente ha bisogno di molto design. Ma penso che sia facile rimanere paralizzati dall'enormità del design; Trovo che ci sia una fase imbarazzante dopo aver scoperto che cosa sono tutti i pezzi grandi, ma prima che sia chiaro per me cosa o come dovrei codificare.

A quel punto, mi piace iniziare a scrivere dichiarazioni di classe. Ovviamente, tutto ciò che sto scrivendo sarà probabilmente scartato o drammaticamente cambiato, ma mi sento come se avessi una migliore padronanza del progetto una volta iniziato a lavorarci. Quindi passerò un paio d'ore a scrivere il codice, poi tornerò al mio progetto e lo affinerò - probabilmente ho pensato ad un altro pacchetto di cui ho bisogno, o ho cambiato le mie idee sulla gerarchia che sto costruendo. Poi, quando il mio disegno sembra aver senso di nuovo e / o mi blocco, torno al codice. Dopo alcune iterazioni di questo, il mio design è completo e ho una buona padronanza su ciò che deve essere fatto - e quando so esattamente che cosa deve essere fatto, è spesso molto chiaro quale ordine dovrebbe fatto.