Approccio allo sviluppo e al test dei moduli

Quello che hai letto da qualche parte è molto vero. Quando si lavora su un software, si desidera ridurre al minimo tutti i loop di feedback (questo è il principio principale dietro lo sviluppo agile / snello). Prima scoprirai che è necessaria una correzione, più facile (sforzo, rischio ...) sarà quello di fare quella correzione.

Quindi, se dovessi scegliere tra i due approcci che hai elencato, vorrei andare con (1), sviluppare / testare il modulo alla volta perché l'altro approccio ha il più ampio ciclo di feedback che potresti avere. Scrivere un intero programma e solo dopo averlo testato sta chiedendo un disastro.

Tuttavia, voglio segnalarvi alcune altre cose:

Sembra che si assuma che "un bug" sia un errore di codifica. E sì, gli errori di codifica sono bug, ma quando si creano software è necessario essere a conoscenza di altri tipi di bug:

• bug di progettazione: il tuo codice funziona come previsto ma il tuo design non funziona. Forse è troppo complesso, forse non riesce ad affrontare correttamente i requisiti.
• bug di requisiti: il tuo codice funziona come previsto e come progettato, ma la tua comprensione di ciò di cui l'utente ha bisogno non è corretta. A volte quell'utente sei tu. Può capitare che ti immagini come vuoi che la tua app appaia e si comporti. Quindi crei un'interfaccia utente per esso e scopri che il tuo piano originale era completamente inadeguato perché non riesce a risolvere (o risolvere elegantemente) qualsiasi problema il tuo programma è destinato a fare.

Nessuno dei tuoi approcci è buono per trovare questi altri tipi di bug. E proprio come i bug di programmazione sono più economici da risolvere non appena li scrivi, i requisiti e i bug di progettazione sono anche più economici da sistemare non appena deciderai sulla strategia e prima di scrivere troppo codice. Dopo che il programma è stato fatto per lo più, i bug di progettazione diventano molto più costosi di quelli di programmazione. E i bug dei requisiti spesso implicano la necessità di riscrivere completamente un blocco del tuo programma.

In altre parole, immagina che il tuo programma sia composto da pochi moduli. Scrivi e collaudi il primo modulo e tutto sembra a posto. Quindi scrivi e testa il secondo e il terzo modulo e le cose sembrano ancora buone. Poi vai a metterli insieme solo per scoprire che il design del modulo A non è veramente adeguato per integrarsi in modo efficiente con il modulo B. Così ora sei tornato, ridisegnando, codificando e ripetendo il modulo A, cosa che comunque avevi già fatto. Il tempo sarà sprecato.

Un approccio migliore sarebbe quello di creare un'architettura di alto livello (layout generale dei moduli) per il tuo programma. Forse hai un'interfaccia utente, alcune logiche di business, alcuni moduli di comunicazione e archiviazione dei dati. Scrivi un minimo indispensabile (essenzialmente solo un codice skeleton) in TUTTI i moduli e poi prova l'intero programma. Anche se tutto ciò che fa è avviare e spegnere senza alcun lavoro utile. Assicurati che l'avvio funzioni. Quindi aggiungere una funzionalità al programma. Questa funzione interesserà probabilmente molti / tutti i tuoi moduli. Verificare che la funzionalità funzioni. Continua a farlo fino a quando il tuo programma è terminato.

In questo modo non passerai troppo tempo nel modulo A, prima di capire come tutto il programma si riunisce. Sarai anche in grado di vedere l'interfaccia utente dal vivo e sarai in grado di interagire con esso, quindi se qualcosa deve cambiare sarai in grado di apportare modifiche prima che venga scritto troppo altro codice.

La gestione della risoluzione dei bug deve essere gestita caso per caso e pianificata in base alle esigenze aziendali e alla natura del bug stesso.

Detto questo, se si identifica un bug mentre si sta lavorando su un codice, e se il bug influenzerà la capacità di continuare a implementare una funzionalità, probabilmente sarà gestito meglio in tempi relativamente brevi e quindi programmato come priorità. Se tuttavia il bug viene rilevato ma non interessa direttamente la funzionalità che si sta implementando, è necessario registrarlo e, come minimo, eseguire un piccolo debug per determinare l'estensione e la gravità del bug rilevato, quindi pianificare di conseguenza, o alla fine di un'iterazione, o alla fine di un progetto, o anche come parte della manutenzione post-rilascio se il bug non è molto probabile che appaia, o non è molto grave in natura.

Idealmente, staremmo tutti scrivendo software senza errori. Tuttavia, il più vicino possibile a questo ideale è scrivere software in modo da ridurre al minimo le opportunità di comparsa degli errori. Qui è dove i seguenti ideali, come SOLID, Clean Code, Behaviour / Test driven development, YAGNI, Refactoring, e tutte quelle altre adorabili piccole parole che siamo così dipendenti possono essere di grande beneficio. In particolare, la chiave è mantenere i nostri progetti e codici semplici, snelli e puliti il più possibile, e con un alto grado di copertura del test. In sostanza, il problema è stato risolto in anticipo per evitare che i bug finissero prima del controllo.

Ovviamente, non supererai mai veramente quegli errori causati da requisiti poco chiari e da una logica imperfetta, ma con un buon approccio metodico allo sviluppo di un software robusto fin dall'inizio, ridurrai efficacemente l'importo di ricerca di bug che probabilmente dovrai fare in seguito.

Di solito ci sono due problemi nel ritardare la correzione dei bug: 1) Non sai quanto tempo ci vorrà per risolverli; 2) Altre parti del codice che dipendono dalla parte del buggy possono essere bacate o funzionare bene fino a il bug è corretto (e più tardi diventa bacato).

Per il primo problema, è importante tenere traccia e dare priorità ai bug, poiché in pratica è difficile risolvere ogni piccola cosa che si incontra direttamente sul posto (specialmente se si è in una scadenza). Se un bug deve essere corretto prima di una determinata versione, correggilo il prima possibile, in modo da poter gestire meglio la tua pianificazione (eliminando l'attività imprecisa, più la precisione sarà più facile da gestire).

Il secondo problema, tuttavia, è molto significativo: a meno che il tuo progetto sia particolarmente chiaro (quindi puoi tenere traccia delle parti del tuo programma che dipendono da quali altre parti) il ritardo delle correzioni di bug introdurrà molti più problemi, e otterrà peggio, più tempo passa. Per questo motivo, lo sviluppo di moduli che dipendono da esso prima di correggere i suoi bug è più spesso di una ricetta per problemi.

Quindi, la mia risposta alla tua domanda è: non devi necessariamente correggere tutti i bug in un modulo prima di passare al successivo, ma se il modulo B dipende dal modulo buggy A, correggi tutti i bug noti in A prima di iniziare la codifica modulo B.

Dipende dal tuo requisito di progetto. Se il tuo progetto contiene moduli che sono praticamente indipendenti, puoi dividere il tuo progetto in modulo e poi testarlo come unità, correggere bug. Infine integra tutti i moduli

Ma secondo caso, se il modulo è altamente correlato e hanno una strong comunicazione tra di loro. Quindi non possiamo testare un modulo in modo indipendente. Quindi dovresti prima codificare e testare il maggior numero possibile di funzionalità che puoi testare. Quindi vai a test completi dopo l'integrazione e correzione bug.

Nel secondo caso aumenta il sovraccarico su uno sviluppatore.