Il giusto mix di pianificazione e programmazione su un nuovo progetto

Sei sulla strada giusta. Non è necessario passare mesi a pianificare, ma è necessario disporre di una sorta di piano.

La pianificazione ti aiuterà a organizzare i tuoi pensieri, a identificare le tecnologie che potresti avere bisogno, a chiarire i punti problematici ea darti una tabella di marcia per lavorare da cui puoi suddividerli in obiettivi misurabili.

Inoltre, potresti dedicare qualche giorno alla pianificazione solo per scoprire che questo è uno spreco di tempo. Forse mentre stai pianificando, ti rendi conto che sei fuori dal tuo campionato o che quello che stai cercando di fare non può essere commercializzato. È meglio scoprirlo ora in modo da poter ri-investire il tuo tempo in altre idee che hai, piuttosto che percorrere questa strada solo per perdersi nei boschi, circondati da code di codice e scie di logica fallibile che ti torcono il cervello in nodi.

Pianifica il prodotto minimo vitale e implementalo. Quindi ascolta i tuoi utenti e pianifica il prossimo miglioramento logico e implementalo. Ripeti.

Indipendentemente dal tempo che dedichi alla pianificazione e alla progettazione del tuo programma, finisci sempre per riscriverne comunque parti. È come la gravità, non è intelligente negare la sua esistenza.

È necessario rendersi conto che il refactoring è una parte normale dello sviluppo ed è solo questione di decidere quando lo si fa. Aspetta a lungo e finisci con enormi quantità di spaghetti, implorando una completa riscrittura. Non divertente.

Il mio suggerimento è di pianificare un po 'ma iniziare a codificare al più presto e refactoring, refactoring, refactoring per mantenere il codice in forma. Il principio DRY (non ripetersi) è un ottimo indicatore per questo.

Quando sono in questa posizione, a volte utilizzo TDD (sviluppo basato su test) e inizio a pianificare alcuni test per la parte più complessa del sistema che sto sviluppando. In alternativa, potrei mettere insieme un pseudo codice di alto livello, sempre per le aree più complesse. Trovo questo processo mi dà un piano di azione libero e mi aiuta a identificare quali aree sono probabilmente più che richiede tempo.

Per me questo approccio funziona perché vive da qualche parte tra la programmazione e la programmazione. Una volta che hai le tue idee di prova e / o lo pseudo codice, puoi lavorare attraverso ogni sezione logica e implementare il codice. Io spesso affronterò la parte più difficile di una soluzione proposta, perché in genere la parte più difficile è la caratteristica principale dell'applicazione e puoi sempre ritardare qualsiasi campanello e fischio.

Dato che commenta che la maggior parte del codice è nella tua testa e sei pronto per immergerti e programmare, l'utilizzo di questo approccio può aiutarti a concentrarti su ogni sezione senza che la tua mente diventi annebbiata dal sistema nel suo complesso.

Per riassumere più sinteticamente, si potrebbe dire "affrontare prima la parte più difficile, dividere e conquistare, con pseudo codice e / o piani TDD"!

Basta provare a rendere modulare il codice. Qualunque altra cosa che pianifichi è probabile che venga espulsa durante la successiva iterazione.

Consiglierei di scrivere le tue idee almeno. A seconda delle dimensioni del progetto, potrebbe non essere necessaria molta pianificazione formale. Se tuttavia è molto grande, potresti voler risparmiare un mal di testa e passare un paio di giorni a pianificare in modo più approfondito.