Quale sarà il modo migliore per gestire il codice sorgente recensito in un repository di controllo sorgente? Il codice sorgente deve passare attraverso un processo di revisione prima di essere registrato, o la verifica del codice dovrebbe avvenire dopo che il codice è stato eseguito? Se la revisione avviene dopo che il codice è stato archiviato nel repository, come dovrebbe essere tracciato?
Google ha le migliori pratiche di revisione del codice di qualsiasi luogo che abbia mai visto. Tutti quelli che ho incontrato sono in completo accordo su come fare le revisioni del codice. Il mantra è "rivedere presto e spesso".
Supponiamo che tu usi un processo che assomigli a quello suggerito da Graham Lee. (Il che è un processo che in precedenza avevo usato io stesso.) Il problema è che ai revisori viene chiesto di guardare grossi pezzi di codice. Questo è uno sforzo molto più grande ed è più difficile convincere i revisori a farlo. E quando lo fanno, è più difficile convincerli a fare un lavoro approfondito. Inoltre, quando notano problemi di progettazione, è più difficile convincere gli sviluppatori a tornare indietro e ripetere tutto il loro codice di lavoro per migliorarlo. Stai ancora catturando cose, ed è ancora prezioso, ma non ti accorgi che ti manca più del 90% del vantaggio.
Al contrario, Google ha la revisione del codice su ogni singolo commit prima che possa entrare nel controllo del codice sorgente. Ingenuamente molte persone pensano che questo sarebbe un processo pesante. Ma in pratica non funziona così. Risulta molto più semplice rivedere piccoli pezzi di codice in isolamento. Quando vengono trovati dei problemi, è molto meno lavoro cambiare il progetto perché non hai ancora scritto un mucchio di codice attorno a quel progetto. Il risultato è che è molto più semplice eseguire un'accurata revisione del codice e molto più facile da correggere i problemi.
Se desideri fare una revisione del codice come fa Google (che consiglio davvero, davvero), c'è un software che ti aiuta a farlo. Google ha rilasciato il suo strumento integrato con Subversion come Rietveld . Go (il linguaggio) è sviluppato con una versione di Rietveld che è stata modificata per essere utilizzata con Mercurial. C'è una riscrittura per le persone che usano git con il nome Gerrit . Ho anche visto due strumenti commerciali consigliati per questo, Crucible e Review Board .
L'unico che ho usato è la versione interna di Rietveld di Google, e ne sono rimasto molto soddisfatto.
Una tecnica che ho usato su più squadre è questa:
È responsabilità del codice dell'autore richiedere la revisione e la responsabilità del maintainer della filiale di rilascio per garantire che venga unito solo il codice revisionato.
Esistono strumenti che supportano la revisione del codice, ma non li ho mai usati. È possibile tenere traccia di chi ha effettuato la revisione per qualsiasi fusione all'interno del repository. Ho usato le proprietà di svn e i lavori di perforazione allegati ai commit per mostrare chi ha recensito cosa.
Non ho mai separato il codice per la revisione con criteri commessi / non commessi: l'unico criterio che ho riscontrato è che i test di unità e di integrazione sono verdi.
Per quanto riguarda il monitoraggio, consiglierei di aggiornare il flusso nel tuo tracker dei problemi preferito. Per exampe anziché:
Potresti voler introdurre un altro stage (revisione):
Pertanto, per ogni ticket nello stato Implementato puoi assegnare un revisore e solo i ticket esaminati avanzeranno al QA.
Ho solo l'esperienza delle revisioni del codice, quindi non posso dire quanto sia bello.
Lavoravo con un piccolo gruppo (~ 10-15) di codificatori e stavamo usando VS Team Foundation Studio. Ci è stato chiesto di impegnare il codice una volta al giorno e prima che ogni codice di commit venisse esaminato da qualcun altro nel gruppo (eventualmente da qualcuno coinvolto nel progetto). Durante il commit, il nome della persona è stato incluso anche in un campo.
Ho lavorato su un team che ha esaminato il codice su tutto ciò che è stato archiviato in base a una modifica per modifica durante un paio di recensioni a settimana. Ciò significava che non eravamo sempre aggiornati sulle revisioni del codice, ma abbiamo raggiunto ciò che intendevamo raggiungere.
Quindi, prima, chiedi cosa vuoi ottenere rivedendo il codice. Nel nostro caso, non è stato per catturare gli sviluppatori idiota, c'era un'assunzione di competenza piuttosto che un'assunzione di incompetenza. Ciò ha consentito al team di ottenere una panoramica di altre aree del sistema e ha consentito di correggere alcune decisioni di progettazione discutibili prima che diventassero scolpite nella pietra. Con discutibile, voglio dire, c'è sempre più di un modo per scuoiare un gatto, e non tutti sanno che c'è un coltello per scuoiare i gatti già nella cassetta degli attrezzi, per così dire.
Il modo in cui abbiamo affrontato le revisioni del codice era che ogni attività del nostro software di tracciamento del progetto è stata esaminata. Al momento stavamo usando Mantis e SVN. I nostri commit del progetto erano legati ad entrambi i sistemi. Ogni impegno doveva essere legato a un compito in mantide. Una volta completata l'attività, gli è stato assegnato lo stato "Pronto per la revisione".
Gli articoli RFR sono stati raccolti da chiunque avesse un po 'di tempo libero per le recensioni o era stato assegnato a una persona specifica per la revisione. Il venerdì tutti gli articoli RFR dovevano essere esaminati prima della fine della giornata in modo che non ci fossero riporti alla settimana successiva.
Gli unici problemi che abbiamo incontrato in questo processo sono stati gli articoli di grandi dimensioni che contenevano un sacco di file. Per gestire ciò, il codificatore e il revisore si riunirebbero e il programmatore avrebbe eseguito le modifiche finché il revisore non le avesse comprese. Farebbero la revisione del codice insieme.
Questo processo si è interrotto quando la direzione ha imposto che, se fosse stata effettuata la peer programming, non sarebbe stata necessaria una revisione separata del codice. Gli sviluppatori sono diventati rilassati riguardo al processo e sono stati introdotti piccoli errori stupidi. Alla fine siamo tornati al processo originale e le cose sono tornate insieme.
Nel mio team abbiamo utilizzato una pratica nell'ultimo anno o giù di lì che sembra funzionare molto bene.
La nostra organizzazione utilizza Perforce per il controllo della versione. Perforce (a partire da un anno fa) include una funzionalità chiamata Shelving. Con scaffalature, posso "accantonare" i miei cambiamenti per un particolare problema. Sono archiviati nel sistema di controllo della versione ma non vengono registrati. Quindi chiedo a un altro sviluppatore del mio team di rivedere il codice.
L'altro sviluppatore può visualizzare le mie modifiche in sospeso in Perforce dal proprio computer e confrontare le modifiche alle revisioni più recenti. Può anche "sgomberare" sulla sua macchina locale se vuole provare i miei cambiamenti. Quando ha completato la recensione, mi fa sapere. Poi controllo il mio codice con "Inviato da Bob" alla fine del commento.
Questo ha funzionato molto bene per noi. Innanzitutto, le recensioni del codice in generale si sono dimostrate estremamente utili. Inoltre, la funzione di scaffalatura di Perforce ci consente di effettuare le revisioni senza effettuare il check-in o le principali difficoltà anche se il nostro team è geograficamente diffuso, il che è molto importante. E funziona alla grande.
Leggi altre domande sui tag version-control code-reviews svn