Puntare a una revisione del codice al 100% di ogni riga di codice prodotta è probabilmente irrealistico. Ciò richiederebbe molto tempo per gli sviluppatori / tester, riducendo lo sforzo dedicato alla produzione effettiva di software. Ci sono due cose su cui devi decidere - cosa vuoi rivedere e come vuoi rivederlo.
Ciò che recensisci dipende da molti fattori. Ad esempio, probabilmente si desidera rivedere il codice coinvolto nelle funzionalità più importanti. Se hai un nuovo sviluppatore nel team, questo è un altro codice che desideri esaminare per garantire che il nuovo sviluppatore stia seguendo le linee guida sulla codifica e stia producendo un prodotto di qualità. Una volta che hai una metodologia per determinare quanto sia importante condurre una revisione del codice su una data unità, quella metodologia dovrebbe essere documentata (forse come lista di controllo) in modo che altri possano valutare il proprio codice e sapere quando chiedere una revisione e quando non è necessario.
Esistono molti metodi per condurre una revisione del codice . Si va dalla programmazione della coppia alle ispezioni formali. I metodi utilizzati spesso dipendono dalla gravità del codice. Se si tratta di un blocco fondamentale per la vita, allora forse si desidera utilizzare un processo di ispezione formale, con più revisori che leggono il codice, lo annotano, quindi si incontrano con lo sviluppatore. Se si tratta di una correzione di bug prodotta da un nuovo sviluppatore, allora un altro punto di vista mentale potrebbe essere sufficiente.
Per il tuo caso specifico di revisione del codice di un nuovo sviluppatore, utilizzerei un approccio più leggero, come ad esempio la lettura di un codice over-the-shoulder. Se hai le persone, la programmazione delle coppie potrebbe essere migliore, dal momento che non solo raggiungerebbe gli obiettivi di garantire che non commettessero errori, ma anche di lavorare a stretto contatto e di conoscere un membro del team. Cercherò sicuramente di andare con qualcosa di più personale, però, con l'interazione umana e non solo con l'e-mail, per migliorare l'esperienza del team-bonding quando realizzo ancora gli obiettivi della recensione.
Gli approcci migliori variano a seconda del team, ma se consideri le tue opzioni in merito alla criticità del codice, allo scopo della revisione del codice e a quanto tempo e denaro hai, puoi elaborare un processo di revisione del codice . Si noti inoltre che le stesse linee guida generali possono essere applicate a qualsiasi prodotto di lavoro: requisiti, disegni, manuali utente ...