Cosa dovrebbe venire prima: test o revisione del codice?

Sono abbastanza nuovo nella programmazione dei modelli di progettazione e dei cicli di vita e mi chiedevo, cosa dovrebbe venire prima, revisione del codice o test, per quanto riguarda il fatto che questi vengono fatti da persone separate?

Da un lato, perché preoccuparsi di rivedere il codice se nessuno ha verificato se funziona? Dall'altro, alcuni errori possono essere trovati in anticipo, se si esegue la revisione prima del test.

Quale approccio è raccomandato e perché?

Test di unità di sviluppo prima, quindi revisione del codice, quindi test di QA è come lo faccio. A volte la revisione del codice avviene prima del test dell'unità, ma di solito solo quando il revisore del codice è veramente sommerso e questa è l'unica volta in cui può farlo.

Il nostro standard è fare la revisione del codice prima che il prodotto passi al QA. Il motivo è che una volta che il prodotto è stato testato e verificato, c'è meno incentivo a fare refactoring e modificare in altro modo il codice interno. Dovrebbe quindi essere nuovamente testato. Si noti che eseguiamo anche test unitari nella maggior parte dei casi.

Idealmente, in un mondo Agile, entrambi :)

Lo sviluppo test-driven è un metodo che incoraggia lo sviluppo di unit test prima della scrittura del codice effettivo: in questo modo è possibile acquisire le specifiche nel codice e scrivere test che superano i test. In seguito, i test di integrazione automatizzata che assicurano che tutti i diversi componenti si incastrino sono una buona cosa per garantire ulteriormente che la funzionalità dell'applicazione corrisponda a quanto previsto.

Per quanto riguarda le revisioni del codice, la programmazione delle coppie è un modo utile per avere un'altra mente che trascura il codice mentre lo stai scrivendo. Tuttavia, questo non è necessariamente un approccio pratico. Il modo in cui funziona nella mia attuale azienda è che il codice viene rivisto dopo che è stato testato sulla macchina personale dello sviluppatore, ma prima che sia stato distribuito su un server di sviluppo condiviso.

La revisione del codice viene eseguita per "lucidare" le cose che già funzionano, per assicurare che il codice abbia il livello di qualità desiderato e soddisfi le linee guida del codice definite dalla società.

La revisione del codice può anche avvenire come parte della futura attività di ottimizzazione generale in cui si esegue il refactoring e si migliora il vecchio codice.

Se pratichi la revisione del codice prima di effettuare un check-in, la revisione del codice rientra tra due fasi di test: tu come sviluppatore test prima il tuo codice, il tuo peer esegue la revisione del codice, esegui il check-in, quindi i tester dedicati eseguiranno individualmente più approfonditi e test di integrazioni.

Prima prova. Prova per ultima. Test, test, test.

La revisione del codice è interessante. Ma difficile - può essere un processo doloroso se sono coinvolte personalità o opinioni diverse.

Il test è molto chiaro: o funziona o non funziona. Quindi prova, prova, prova! E la revisione del codice, se possibile.

Nel mio ultimo lavoro abbiamo avuto tre diversi tipi di revisioni del codice che avremmo fatto in diverse fasi del ciclo di vita del prodotto. Il primo tipo che abbiamo chiamato Sanity Review, e sarebbe accaduto prima che uno sviluppatore avesse anche effettuato test di unità, infatti Sanity Review era stato fatto anche prima che le funzionalità fossero completate. L'idea era che una coppia di membri del team si sarebbe seduto e avrebbe esaminato alcune sezioni casuali di codice durante il processo di sviluppo, per assicurarsi che lo sviluppo andasse bene e non avremmo finito con un gigante Voce TDWTF una volta che la funzione era pronta per essere unita. Questo è stato fatto principalmente per le persone che avevano bisogno di una guida extra (sviluppatori junior, nuovi assunti e persone assegnate a lavorare su qualcosa con cui avevano meno familiarità rispetto agli altri membri del team), e generalmente tenuto a una breve riunione che ha affrontato solo problemi gravi.

Successivamente abbiamo avuto recensioni di unità. Questi venivano generalmente eseguiti con tre sviluppatori e sarebbero stati eseguiti quando un'unità / funzione era stata testata ed era pronta per essere unita all'albero principale. Questa è stata la recensione più magro e sarebbe entrata in un bel po 'di dettagli. Avevamo tre sviluppatori per questo perché avevamo l'autore originale del codice, il manutentore dell'albero che doveva firmare il codice prima che potesse essere unito, e un terzo sviluppatore che era stato selezionato come backup per lo sviluppatore originale (con l'idea che una volta completata una sezione di codice, ci dovrebbe essere un trasferimento completo delle conoscenze a un altro membro del team, quindi c'erano sempre almeno 2 persone nel team che erano perfettamente a proprio agio con qualsiasi parte della base di codice).

Infine, abbiamo avuto recensioni di progetti. Ciò comprendeva l'intero team e richiederebbe circa una settimana, ed è stato fatto dopo il QA e il lancio del prodotto, e l'obiettivo era quello di far sedere tutti e passare attraverso tutte le modifiche all'intera base di codice nell'ultimo ciclo di rilascio, dove tutti potevano parlare di cambiamenti architettonici, gotchas e decidere cosa necessitare di refactoring e correzione prima di iniziare lo sviluppo della prossima versione del progetto.

Innanzitutto, scrivere test automatici per il codice da sviluppare. Rivedere i test per accertarsi che tutti i requisiti noti siano in fase di test. Scrivi il codice Rivedere tutte le volte che lo desideri.

Se è richiesto un test manuale, è fondamentale rivedere il codice prima di eseguire qualsiasi test manuale. In caso contrario, i miglioramenti del design suggeriti nella revisione del codice verranno rifiutati perché i test manuali dovranno essere rieseguiti.

Qual è il primo, l'uovo o il pollo?
Dipende.

Se sei nuovo e non sei sicuro di ciò che fai, allora chiedi a un pari di darti un po 'di aiuto. Questa è una recensione di codice informale ma molto seria e preziosa.

In genere, però, suggerirei di fare prima il tuo lavoro sporco, assicurati di aver appianato il codice, di averlo commentato bene nei posti giusti (cioè i pezzi difficili, non quelli ovvi), almeno funziona fondamentalmente (hai testato ai minimi casi generali e ad alcuni casi limite o eccezioni). Quindi lo porti al tuo pari.

Revisionare il codice troppo presto potrebbe finire in una terribile perdita di tempo del tuo pari. Farla revisionare troppo tardi potrebbe finire con un terribile spreco di tempo. Devi trovare il giusto equilibrio per la massima efficienza. Quindi alcuni test vanno prima, poi la revisione, quindi altri test. Potenzialmente potresti avere diverse revisioni del codice, a seconda della complessità e delle iterazioni, con scopi e obiettivi diversi.

Meno sei sicuro di più recensioni (quando sei nella fase iniziale di apprendimento, questo è normale). Più sei sicuro anche di più recensioni (non è mai bello essere troppo sicuri di te, ciò significa che generalmente non sei un bravo giocatore di squadra e potresti mettere in difficoltà gli altri, devi assicurarti che il tuo codice possa essere compreso e usato da altri). È quando sei nel mezzo che le recensioni possono essere distanziate un po '.

Solo i miei due centesimi.

Capers-Jones, che ha studiato e misurato l'efficienza e la qualità dei processi di sviluppo del software risultanti più di chiunque altro, raccomanda la seguente sequenza di attività di rimozione dei difetti:

• Ispezioni di progettazione
• Ispezioni del codice
• Test unitari
• Nuovi test funzionali
• Test di regressione
• Test delle prestazioni
• Test di sistema
• Beta test esterni

Uno dei motivi per condurre l'ispezione del codice prima del test è che la revisione può considerare non solo il codice stesso, ma la testabilità del codice.