Riconoscere che c'è un modo migliore di provare & l'errore è il primo passo.
Di solito inizio con carta e amp; matita. Ho un'idea approssimativa di ciò che chiede il cliente e delinea l'esperienza utente. Ho bisogno di sapere cosa l'utente ha bisogno di vedere, cosa devono fare, ecc. Per progetti più grandi, questo si evolverebbe in documenti Requirements, specifiche funzionali, una visione, ecc. Vorrei anche identificare le storie degli utenti su un ruolo base.
Il mio prossimo passo è guardare da dove provengono i dati, come lo memorizzerò, quali manipolazioni (se ce ne sono) che devo fare su di esso, ecc. Ciò include sia la memoria in-memory che il database ( non tutti i programmi richiedono un database). Strutture dati sono tuoi amici. Scegliere la giusta organizzazione dei dati farà la differenza tra un programma che è un piacere usare e amp; uno che è appena tollerabile.
L'organizzazione del programma viene dopo - quali oggetti ho, come comunicano, come faccio a separare le funzionalità in modo da separare cose che cambiano da cose che non lo fanno, come faccio a mantenere le cose DRY , ecc.
Ci sono alcuni disegni in scatola (come model-view-controller ) che può essere utile. Il trucco è sapere quando i disegni sono appropriati e quando non lo sono, non soffri di sindrome del martello .
Appena prima di iniziare a scrivere il codice, do un'ultima occhiata al mio piano e cerco cose da rimuovere. C'è un termine per questo: " YAGNI ". Inoltre, ricorda: non è necessario correggere le funzioni che non si rispettano.
A questo punto ho l'inizio di un piano - quando mi siedo alla tastiera ho un'idea di quello che sto cercando di realizzare.
Potresti anche leggere su Test Driven Development - è una tecnica molto buona, ma non da stessa risposta alla tua domanda.