Dove posso trovare / Quali sono i passi / la strategia corretti da pianificare prima della codifica? [chiuso]

Il primo passo è decidere cosa vuoi che faccia il tuo programma. Fai un elenco dettagliato delle funzionalità che desideri che il tuo programma abbia. E una volta deciso, evita di aggiungere qualcosa di nuovo a metà dell'implementazione. Se si progetta il codice correttamente, si dovrebbe essere in grado di aggiungere nuove funzionalità con relativa facilità in seguito.

Decidi chi sta utilizzando il tuo programma e in che modo interagiranno con esso. È un cliente specifico per il quale lo stai progettando? In tal caso puoi permetterti di specializzare il design del programma in base alle preferenze dei tuoi clienti. Lo stai progettando per un vasto pubblico? In tal caso vorrai che sia più personalizzabile, ma semplicistico. Avrai anche bisogno di mettere più pensiero in apparenza. gli utenti interagiranno con un server? Se è così, ti consigliamo di progettare il tuo programma per renderlo scalabile.

Decidi su come intendi progettare il programma. Il tuo programma sarà guidato dagli eventi? In tal caso, utilizzerai un sistema di polling degli eventi o avrai gestori di eventi? Se il tuo programma deve essere scalabile, il tuo progetto consente miglioramenti di runtime senza tempi di inattività massivi? Sarai in grado di migliorare facilmente le prestazioni di runtime senza enormi riscritture? Pensa in modo approfondito alla scelta del design, perché se non lo fai, può comportare il riavvio da zero.

Dopo tutto questo è fuori strada, inizia a pensare a come strutturerai il tuo codice. Questo è un intero processo tutto suo, quindi non approfondirò, indicherò solo alcune cose da evitare.

1) Non utilizzare interfacce / classi astratte se non è necessario. Non sono caratteristiche magiche che dovrebbero essere usate in ogni occasione, contrariamente a quanto dicono le persone. Possono portare a massicci problemi di reimplementazione e un design scadente.

2) non usare troppo l'ereditarietà. Per la stessa ragione sopra indicata.

3) non sovrascrivere il tuo codice. Non hai bisogno che tutto sia il più veloce possibile se tutto quello che stai facendo è ordinare un piccolo contenitore con 30 elementi. Non è necessario rendere tutto il più astratto possibile. Se i benefici non possono essere osservati né attraverso le prestazioni, né la leggibilità / manutenibilità del codice, non ne vale la pena.

4) assicurati di rendere il tuo codice modulare quando possibile. Farà più facile aggiungere o rimuovere funzionalità in futuro.

Ecco alcuni suggerimenti di base che posso offrirti.

Hai praticamente identificato il tuo problema qui e sei sulla strada giusta.

Come accennato nella risposta di Imnota4, niente batterà un po 'di pianificazione. Penna e carta (o lavagna o qualsiasi cosa galleggi la tua barca) è tuo amico qui. Lo scopo qui non è quello di scrivere una specifica dettagliata del software, è incredibilmente difficile arrivare fin dall'inizio. Mi chiedo se sono persino possibile per più del software più banale. Vuoi solo liberarti del caos e cercare di organizzarlo un po 'prima di iniziare. Pensa di scaricare un secchio di Lego e iniziare a selezionarli, non tutti, solo quanto basta per iniziare.

• Qual è il problema che cerchi di risolvere , scrivilo. Poche righe, mai più di mezza pagina. Non immergerti nei dettagli su How's e Who's, concentrati solo su What and the Why. È facile perdere di vista quando ci si trova nelle trincee. Questo sarà il tuo faro che ti terrà al corrente.

• Qual è il dato. I dati sono il cuore del tuo software, deve essere. Identifica tutti i dati e disponili, osserva la loro relazione, ciò che deve cambiare nei dati. Modellalo bene, di solito se hai inchiodato come i dati sono il resto diventa molto più facile. Se in un secondo momento trovi che qualcosa è troppo difficile da codificare, non riesci a capire come ottenerlo, torna a come hai modellato i tuoi dati, molto probabilmente c'è qualcosa che non hai previsto o dimenticato di modellare .

• Come sarà usato ? Annota le interazioni che gli utenti avranno con il tuo software. Separali in piccole storie, quindi raggruppa le tue storie insieme da quanto strettamente correlate. Mantenere le storie piccole, la maggior parte di esse sarà banale. Non è una singola storia che descrive il sistema ma la somma di tutti. Non preoccuparti se li prendi subito, però, concentrandoti inizialmente sull'ovvio, lo aggiungerai più tardi man mano che avanzi.

Ora sei pronto per iniziare la codifica!

Sulla maggior parte delle storie dovresti già avere un'idea su come la codifichi, ma spesso alcune di esse ti faranno sentire un po 'più debole. A questo punto tendo a scegliere quello che trovo il peggiore e seleziono in un blocco di codice monolitico in una funzione principale di scratch pad da qualche parte. Ci riuscirò fino a quando l'incertezza non sarà portata a un livello più constrongvole e ho un buon senso su come lo farò.

Ora inizio. Scelgo una storia, implemento la parte dei dati di cui questa storia ha bisogno (e non molto di più) e inizio la codifica. Inizia con le shell, scrivi test attorno a loro per assicurarti che la storia sia valida e codificale finché non supera i test.

Per quanto possibile cerco di trattenermi dall'anticipazione, piuttosto mi rifatto quando necessario mentre realizzo sempre più storie. È abbastanza comune che la prima parte che ho scritto venga riscritta 2, 3, 10 volte, dipende dalla complessità e dal modo in cui il problema è stato risolto all'inizio. Trovo che se anticipo i bisogni futuri implementandoli ora, piuttosto che risparmiare tempo, finisco per dover refactoring comunque e ora ho solo più cose a cui pensare. Spesso le volte in cui quello che pensavo di cui avevo bisogno risulta del tutto inutile, ho trovato un modo più intelligente per farlo.

Spero che questo aiuti