Sono abbastanza nuovo nella programmazione di schemi di progettazione e cicli di vita e mi chiedevo, che cosa dovrebbe venire prima, la revisione del codice o il test, in quanto sono fatti da persone separate?
Da un lato, perché preoccuparsi di rivedere il codice se nessuno ha verificato se funziona anche? Dall'altro, alcuni errori possono essere trovati in anticipo, se si esegue la revisione prima del test.
Quale approccio è raccomandato e perché?
Prima test dell'unità di sviluppo, quindi revisione del codice, quindi test del QA è come lo faccio. A volte la revisione del codice avviene prima del collaudo dell'unità, ma solitamente solo quando il revisore del codice è veramente sommerso e questa è l'unica volta in cui può farlo.
Il nostro standard è di fare la revisione del codice prima che il prodotto vada al QA. Il motivo è che una volta che il prodotto è stato testato e verificato, c'è meno incentivo a rifattorizzare e modificare in altro modo gli interni del codice. Dovrebbe quindi essere ritestato. Nota che eseguiamo anche test unitari nella maggior parte dei casi.
Idealmente, in un mondo Agile, entrambi:)
Lo sviluppo basato su test è un metodo che incoraggia lo sviluppo di test unitari 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 automatizzati che assicurano che tutti i vari componenti combacino tra loro sono una buona cosa per garantire che la funzionalità dell'applicazione corrisponda a quanto previsto.
Per quanto riguarda le revisioni del codice, la programmazione della coppia è un modo utile per avere un'altra mente che si affaccia sul tuo 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 esaminato dopo che è stato testato sul personal computer dello sviluppatore, ma prima che sia stato distribuito su un server di sviluppo condiviso.
La revisione del codice viene eseguita per "perfezionare" 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 effettua il refactoring e si migliora il codice precedente.
Se eserciti la revisione del codice prima di effettuare il check-in, la revisione del codice cade tra due fasi di test: tu come sviluppatore testi prima il tuo codice, il tuo peer esegue la revisione del codice, lo controlli, poi i tester dedicati eseguiranno di più approfonditi test individuali e di integrazione.
Prima prova. Prova per ultimo Prova, prova, prova.
La revisione del codice è piacevole. Ma difficile - può essere un processo doloroso se le personalità coinvolte o opinioni diverse.
Il test è molto chiaro: o funziona o non funziona. Quindi prova, prova, prova! E se possibile, riesamina il codice.
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 un Sanity Review, e sarebbe successo prima che uno sviluppatore avesse persino fatto un test unitario, infatti le Recensioni Sanity sono state fatte anche prima che le funzionalità fossero completate. L'idea era che una coppia di membri del team si sedesse e passasse alcune sezioni casuali di codice come era nel processo di sviluppo, per assicurarsi che lo sviluppo stia andando bene e non avremmo avuto un gigante Ingresso TDWTF una volta che la funzione era pronta per la fusione. Ciò è avvenuto principalmente per le persone che avevano bisogno di ulteriore guida (sviluppatori junior, nuovi assunti e persone assegnate a lavorare su qualcosa con cui avevano meno familiarità degli altri membri del team), e generalmente tenuto a un breve incontro che ha affrontato solo problemi eclatanti.
Successivamente abbiamo avuto recensioni di unità. Questi erano generalmente fatti con tre sviluppatori e sarebbero stati eseguiti quando un'unità / funzione era stata testata ed era pronta per essere unita alla struttura principale. Questa è stata la recensione più attenta e andrebbe in un bel po 'di dettagli. Avevamo tre sviluppatori per questo perché avevamo l'autore originale del codice, il manutentore dell'albero che dovette firmare il codice prima di poterlo unire e un terzo sviluppatore che era stato selezionato come backup dello sviluppatore originale (l'idea è che una volta che una sezione di codice è stata completata, ci dovrebbe essere un trasferimento completo delle conoscenze ad un altro membro del team, quindi c'erano sempre almeno 2 persone nel team che erano completamente a proprio agio con qualsiasi parte della base di codice).
Infine, abbiamo avuto revisioni del progetto. Questo comprendeva l'intero team e richiedeva circa una settimana, ed era fatto dopo il QA e il lancio del prodotto, e l'obiettivo era di far sedere tutti e di passare attraverso tutte le modifiche all'intero codebase nell'ultimo ciclo di rilascio, dove tutti potevano parliamo di cambiamenti architettonici, trucchi e decidiamo cosa è necessario rifattare e correggere prima di iniziare lo sviluppo sulla prossima versione del progetto.
Per prima cosa, scrivi test automatici per il codice da sviluppare. Rivedere i test per assicurarsi che tutti i requisiti noti siano in fase di test. Scrivi il codice Rivedi tutte le volte che desideri.
Se sono necessari test manuali, è fondamentale rivedere il codice prima per eseguire qualsiasi test manuale. In caso contrario, i miglioramenti di progettazione 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 quello che fai, allora chiedi a tutti un peer di darti un po 'di aiuto. Questa è una revisione del codice informale ma molto seria e preziosa.
Generalmente però ti suggerisco di fare il tuo lavoro sporco prima, assicurati di aver appianato il codice, l'hai commentato bene nei posti giusti (cioè i bit più difficili, non quelli ovvi), almeno fondamentalmente funziona (hai testato i casi generali minimi e alcuni casi limite o eccezioni). Poi lo porti al tuo pari.
Ottenere il tuo codice rivisto troppo presto potrebbe finire in uno spreco terribile del tempo del tuo pari. Farlo rivedere troppo tardi potrebbe finire in uno spreco terribile del tuo tempo. Devi trovare il giusto equilibrio per la massima efficienza. Quindi alcuni test vanno prima, poi la recensione, quindi più test. Potenzialmente potresti avere diverse revisioni del codice, a seconda della complessità e delle iterazioni, con scopi e scopi diversi.
Meno sicuro di avere più recensioni (quando sei nella tua fase di apprendimento iniziale, questo è normale). Più sei sicuro di avere più recensioni (non è mai bello essere troppo sicuri di te stesso, il che significa che in genere non sei un bravo giocatore di squadra e che potresti mettere altri in difficoltà, devi assicurarti che il tuo codice possa essere compreso e usato da altri). È quando sei nel mezzo che le recensioni possono essere distanziate.
Solo i miei due centesimi.
Capers-Jones, che ha studiato e misurato la risultante efficienza e qualità dei processi di sviluppo del software più di chiunque altro, raccomanda following sequence delle attività di rimozione dei difetti:
Uno dei motivi per cui è stata condotta l'ispezione del codice prima del test è che la revisione possa considerare non solo il codice stesso, ma anche la testabilità del codice.
Leggi altre domande sui tag testing code-reviews