Quanti dettagli mettere nella prima iterazione del progetto?

Ho appena iniziato un nuovo progetto personale (Python) e sto scrivendo ciò che equivale a una "bozza" del programma, il minimo richiesto per fare quello che voglio fare. Non sto ancora inserendo un'ampia gestione di errori / eccezioni o elementi estetici dell'interfaccia utente (anche nei casi in cui so che alla fine queste cose saranno necessarie), e la documentazione è appena sufficiente per aiutarmi in futuro a vedere cosa stavo facendo.

È contro qualche principio prefissato di progettazione / gestione del progetto iniziare così in modo approssimativo? Sono uno scienziato, non un programmatore, quindi non sono al passo con queste cose. Quindi la domanda principale è: esiste un consenso su dove si dovrebbe mirare a cadere tra i due estremi di:

1. Scrivi dall'inizio un codice completo e di alta qualità, con tutta la gestione delle eccezioni e tale da sapere che alla fine ti servirà.

2. Scrivi una bozza approssimativa funzionante minimamente dall'inizio e vai a compilare tutte le minuzie in seguito.

Domanda correlata: quando è OK sacrificare la "pulizia" del progetto per realizzare un 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 arrivarci?

Risultato finale

Stai scrivendo il software di controllo Mars Orbiter? Quindi è meglio assicurarsi che tu stia scrivendo il codice più affidabile possibile, è meglio che tu controlli che ogni eccezione sia gestita in maniera sana.

Stai scrivendo un programma che solo tu eseguirai e che eseguirai solo manualmente ogni tanto? Quindi non preoccuparti delle eccezioni. Non preoccuparti dell'architettura pesante. Fallo funzionare al punto in cui funziona per te.

Come ti aspetti di arrivarci?

Stai facendo un forte sviluppo a cascata, dove passi molto tempo a capire cosa è necessario e poi te ne andrai per mesi, sviluppandoti? Se è così, allora vuoi raggiungere quella qualità target sopra menzionata abbastanza presto. Ottieni tutta la tua infrastruttura di controllo degli errori pianificata all'inizio.

Stai facendo uno sviluppo agile pesante, in cui stai mettendo insieme qualcosa per una settimana o due, che verrà quindi mostrato agli stakeholder, che potrebbero chiedere revisioni radicali, e dove ti aspetti di essere in grado di iterare su molti 1-2 sprint fino a quando non colpisci il bersaglio? Quindi potresti essere meglio ottenere qualcosa che funzioni, ma fragile insieme velocemente e solo aggiungendo cinture e bretelle man mano che i requisiti del prodotto si solidificano.

Se hai il controllo sulla cascata o sulla decisione agile (che in realtà è un continuum non una scelta binaria), prendi quella decisione in base al cambiamento previsto. Se sei sicuro di sapere esattamente come sarà il risultato finale, allora la scelta migliore è la cascata. Se hai solo una vaga idea di ciò di cui hai bisogno, Agile è la scelta migliore. (Agile è più popolare in questi giorni non perché sia ​​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 condurti in una direzione di base.

Posso dire questo per me stesso, se scrivo spesso script unici che sono progettati in modo abissale e non hanno alcun errore nel controllare qualunque cosa. Gestisco anche il codice di produzione, in cui la gestione degli errori e l'architettura attirano molta attenzione. Tutto dipende da cosa stai facendo.

Un'ultima avvertenza: se decidi di eseguire script una tantum che possono essere eseguiti in modo rapido e sporco, assicurati. Sfortunatamente, capita spesso che gli script rapidi e sporchi che fanno qualcosa di interessante vengano sfruttati ampiamente quando altri li notano. Accertarsi che, quando ciò accada, venga concesso del tempo per l'indurimento.

Tutti i concetti e gli schemi di progettazione e codifica del software nascono in risposta ad alcuni problemi. Lo schema o il concetto è una soluzione a quel problema. Nel tempo, alcuni schemi diventano "ben noti" come soluzioni preferibili perché risolvono il problema in modo da soddisfare determinati requisiti di coerenza, familiarità, prestazioni, manutenibilità e così via.

Ne consegue che, se il problema che il modello software deve risolvere non esiste nel tuo software specifico, non è necessario il modello. Inoltre, qualsiasi discussione su quali schemi potrebbe essere necessario al tuo software deve includere anche discussioni dettagliate sul tuo software proposto: che cosa dovrebbe 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 di cui 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 arrendo". Se non hai posti nel tuo codice in cui esistono condizioni del genere, non hai bisogno di eccezioni. In alternativa, è possibile semplicemente restituire un codice di errore ed evitare del tutto l'eccezione.

Man mano che acquisisci esperienza, imparerai a conoscere i modelli di software e quando il loro uso è appropriato. Saprai anche di quanto design iniziale hai bisogno; 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 con Mars Explorers.

Innanzitutto, cerca di capire cosa vuoi che faccia il sistema e annota ciascuna delle singole funzionalità. Questo può essere sofisticato come un intero storyboard utente o semplice come alcuni punti elenco annotati su un pezzo di carta di fronte a te. Ma è importante sapere cosa vuoi che faccia.

Sulla base di ciò redigere 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 è avere un'idea di come implementare il sistema. Ma questo probabilmente si perfezionerà mentre ci lavori, quindi non provare ad andare su complessi e dettagliati.

Tra tutte queste funzionalità, capire quali sono le cose chiave che il programma deve fare: le funzionalità principali.

Quindi implementali uno per uno. Ora la cosa chiave qui è quella di assicurarsi che una volta implementata una funzionalità sia fatta e completamente funzionante - idealmente questo è accompagnato da un test unitario che assicura che continui a funzionare. Di solito vado sul presupposto che sarò così impegnato che non avrò mai il tempo di tornare alla funzione e risolverlo.

Una volta implementate le funzionalità principali, in genere cerco di mettere il sistema in modo che sia il più vicino possibile all'ambiente di produzione. Questo ti dà a) tutti i bug che potresti aver perso in precedenza eb) hai una buona idea della priorità delle funzionalità successive.

Quindi è possibile continuare ad implementare le funzionalità rimanenti secondo necessità.

Codice qualità vs. 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 presume che sia fatto. E che possono darmi il prossimo compito. Non ho molto tempo per rendere il codice più bello dopo il fatto.

Ora, che dire della gestione delle eccezioni?

Se non si desidera implementarlo immediatamente, è possibile elencarlo come un'altra funzione nell'elenco. E quando ci riesci puoi implementarlo. Ma molto probabilmente nel tuo caso ci sono probabilmente molte altre cose che sono prima più importanti.

Tuttavia, vi è un requisito minimo per le eccezioni: assicurarsi che l'utente venga avvisato se qualcosa va storto, non importa quanto brutto possa essere l'output. Non ingoiare eccezioni da qualche parte.