Quanti dettagli inserire nella prima iterazione del progetto?

Non esiste una risposta unica, poiché dipende interamente dal progetto. Dobbiamo pensare a due cose qui. Qual è il tuo obiettivo finale? Come ti aspetti di arrivare?

Risultato finale

Stai scrivendo il software di controllo di Mars Orbiter? Quindi è meglio che tu sia sicuro che stai scrivendo il codice più robusto possibile, è meglio controllare che ogni eccezione sia gestita in modo sano.

Stai scrivendo un programma che solo tu corri e che eseguirai solo manualmente ogni tanto? Quindi non preoccuparti delle eccezioni. Non preoccuparti di architetture pesanti. Fallo funzionare fino al punto in cui funziona per te.

Come ti aspetti di arrivarci?

Stai facendo uno sviluppo a cascata pesante, dove passi molto tempo a capire cosa è necessario, e poi andrai avanti per mesi, sviluppando? Se è così, allora si vuole colpire quella qualità di destinazione di cui sopra abbastanza presto. Ottieni tutti i tuoi errori durante il controllo dell'infrastruttura pianificata all'inizio.

Stai facendo uno sviluppo pesante e agile, in cui stai mettendo insieme qualcosa per una settimana o due, che verrà poi mostrato agli stakeholder, che potrebbero chiedere revisioni radicali e dove ti aspetti di poter iterare su molti aspetti 1- 2 scatti veloci fino a quando non colpisci il bersaglio? Allora potresti stare meglio per far funzionare qualcosa, ma fragile insieme velocemente, e aggiungere solo cinture e bretelle come i requisiti del prodotto si solidificano.

Se hai il controllo sulla cascata o la decisione agile (che in realtà è un continuum e non una scelta binaria), prendi quella decisione in base al cambiamento atteso. Se sei sicuro di sapere esattamente come sarà il risultato finale, Cascata è la scelta migliore. Se hai solo una vaga idea di ciò che ti serve per finire, agile è la scelta migliore. (Agile è più popolare in questi giorni non perché è intrinsecamente migliore, ma perché la seconda situazione è molto più comune.)

Ora trova la tua risposta

Per la maggior parte, la risposta si troverà da qualche parte nel mezzo. Rispondi a entrambe le domande sul tuo progetto e dovrebbe guidarti in una direzione di base.

Posso dirlo da solo, se spesso scrivo script unici che sono progettati in modo abissale e che non hanno errori nel controllare qualsiasi cosa. Gestisco anche il codice di produzione, in cui la gestione degli errori e l'architettura ricevono grandi quantità di attenzione. Tutto dipende da cosa stai facendo.

Un ultimo avvertimento: se decidi di eseguire script one-off che possono essere eseguiti in modo rapido e sporco, assicurati. Sfortunatamente, spesso accade che gli script veloci e sporchi che fanno qualcosa di interessante vengano sfruttati in modo ampio quando altri li notano. Assicurati che, quando ciò accada, venga indicato il tempo per l'indurimento.

Tutti i concetti e i modelli di progettazione e codifica del software sorgono in risposta ad alcuni problemi. Il modello o il concetto è una soluzione a questo problema. Nel tempo, alcuni modelli diventano "ben noti" come soluzioni preferibili perché risolvono il problema in un modo che soddisfa determinati requisiti di coerenza, familiarità, prestazioni, manutenibilità e così via.

Ne consegue che, se il problema che il modello software è destinato a risolvere non esiste nel tuo particolare software, allora non hai bisogno del modello. Inoltre, qualsiasi discussione su quali modelli il tuo software potrebbe necessario deve includere anche discussioni dettagliate sul tuo software proposto: cosa si deve fare? Che problema risolve? Quanti utenti ci saranno? Gli utenti condivideranno i dati in qualche modo? E così via.

Il problema che le eccezioni dovrebbero risolvere è quando succede qualcosa che il codice non può fare nulla. Un esempio potrebbe essere un'operazione File / Apri in cui viene specificato un nome file che non esiste sul supporto di memorizzazione. Le eccezioni danno al codice un modo per dire al chiamante "È successo qualcosa che mi impedisce di continuare, e non c'è nulla che io possa fare al riguardo, quindi mi sto arrendendo." Se non ci sono posti nel tuo codice in cui esistono condizioni simili, allora non hai bisogno di eccezioni. Oppure, puoi semplicemente restituire un codice di errore ed evitare l'eccezione del tutto.

Man mano che acquisisci esperienza, imparerai a conoscere i modelli di software e quando il loro uso è appropriato. Saprai anche in che misura il design iniziale è necessario; di nuovo, ciò dipende totalmente dall'applicazione che stai scrivendo. In altre parole, le piccole utility sono scritte in modo sostanzialmente diverso dalle grandi applicazioni aziendali.

C'è un approccio molto semplice e pratico a questo, che funziona per una vasta gamma di progetti di piccole e medie dimensioni. Anche se probabilmente non funzionerà bene per Mars Explorers.

In primo luogo, stabilisci cosa vuoi che faccia il sistema e prendi nota di ognuna delle singole funzioni. Questo può essere sofisticato come un intero storyboard per l'utente o semplice come alcuni punti elenco annotati su un foglio di carta di fronte a voi. Ma è importante che tu sappia che vuoi che faccia.

In base a ciò viene definita la struttura generale del sistema. Ancora una volta, questo è molto spesso solo un rapido disegno delle diverse classi / moduli e di come si relazionano tra loro, ma potrebbe essere complesso come un intero documento. L'importante è che tu abbia una sorta di idea di come stai per implementare il sistema. Ma questo probabilmente si perfezionerà mentre ci lavori, quindi non cercare di andare a dettagli complessi e dettagliati.

Tra tutte queste funzioni, trovi le cose fondamentali che il programma deve fare: le funzionalità principali.

Quindi implementali uno per uno. Ora, la cosa fondamentale qui è che, in realtà, assicurarsi che una volta implementata una funzione sia fatto e pienamente funzionante, idealmente questo è accompagnato da un test unitario che assicura che funzioni sempre. Di solito vado sul presupposto che sarò così impegnato che non avrò mai il tempo di tornare alla funzione e sistemarla.

Una volta implementate le funzionalità principali, in genere cerco di utilizzare il sistema il più vicino possibile all'ambiente di produzione. Questo ti dà a) eventuali bug che potresti aver perso prima e b) hai una buona idea della priorità delle prossime funzionalità.

Quindi puoi continuare a implementare le funzionalità rimanenti secondo necessità.

Qualità del codice e caratteristiche

Tenendo presente quanto sopra, tendo a sacrificare le funzionalità rispetto alla qualità del codice, se devo rispettare una scadenza. Semplicemente perché, almeno nella mia linea di lavoro, quando finisco qualcosa, la mia gestione assume che sia fatta. E che possano darmi il prossimo compito. Non ho molto tempo per rendere il codice più carino dopo il fatto.

Ora, che ne è della gestione delle eccezioni?

Se non vuoi implementarlo, puoi semplicemente elencarlo come un'altra caratteristica della lista. E quando ci arrivi, puoi implementarlo. Ma molto probabilmente nel tuo caso ci sono probabilmente molte altre cose che sono più importanti prima.

Tuttavia, c'è un requisito minimo per le eccezioni: assicurati che l'utente sia informato se qualcosa va storto, non importa quanto brutto possa essere l'output. Non ingoiare le eccezioni da qualche parte.