Quale sarà il modo migliore per gestire il codice sorgente rivisto in un repository di controllo del codice sorgente? Il codice sorgente deve essere sottoposto a un processo di revisione prima di essere archiviato o la revisione del codice deve essere eseguita dopo il commit del codice? Se la revisione avviene dopo che il codice è stato archiviato nel repository, come dovrebbe essere rintracciato?
Risposte:
Google ha le migliori pratiche di revisione del codice di qualsiasi luogo che abbia mai visto. Tutte le persone che ho incontrato sono completamente d'accordo su come fare le revisioni del codice. Il mantra è "rivedere presto e spesso".
Supponiamo di utilizzare un processo che assomiglia a quello che Graham Lee ha suggerito. (Il che è un processo che avevo usato in precedenza.) Il problema è che ai revisori viene chiesto di esaminare grossi blocchi di codice. È uno sforzo molto maggiore 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 indurre gli sviluppatori a tornare indietro e rifare tutto il loro codice di lavoro per renderlo migliore. Prendi ancora cose ed è ancora prezioso, ma non noterai che stai perdendo oltre il 90% del vantaggio.
Al contrario, Google ha una revisione del codice su ogni singolo commit prima di poter passare al controllo del codice sorgente. Ingenuamente molte persone pensano che questo sarebbe un processo pesante. Ma in pratica non funziona così. Risulta essere massicciamente più semplice esaminare isolatamente piccole parti di codice. Quando vengono rilevati problemi, è molto meno complicato modificare il design perché non hai ancora scritto un sacco di codice attorno a quel design. Il risultato è che è molto più semplice eseguire una revisione approfondita del codice e molto più semplice risolvere i problemi modificati.
Se desideri fare una revisione del codice come fa Google (cosa che consiglio davvero, davvero), c'è un software che ti aiuta a farlo. Google ha rilasciato il suo strumento integrato con Subversion come Rietveld . Go (la lingua) è sviluppato con una versione di Rietveld che è stata modificata per l'uso con Mercurial. C'è una riscrittura per le persone che usano git di nome Gerrit . Ho visto anche due strumenti commerciali raccomandati per questo, Crucible e Review Board .
L'unica che ho usato è la versione interna di Google di Rietveld, e ne sono rimasto molto soddisfatto.
Una tecnica che ho usato su più team è questa:
È responsabilità dell'autore del codice richiedere la revisione e la responsabilità del manutentore del ramo di rilascio assicurarsi che solo il codice rivisto venga unito.
Esistono strumenti che supportano la revisione del codice, ma non li ho mai usati. Il monitoraggio di chi ha effettuato la revisione per qualsiasi unione può essere eseguito all'interno del repository. Ho usato proprietà svn e lavori perforce associati a commit per mostrare chi ha recensito cosa.
Non ho mai separato il codice per la revisione da criteri impegnati / non impegnati - l'unico criterio che ho incontrato è che i test unitari e i test di integrazione sono verdi.
Per quanto riguarda il monitoraggio, consiglierei di aggiornare il flusso nel tracker dei problemi preferito. Per esempio anziché:
Potresti voler introdurre un'altra fase (recensione):
Pertanto per ogni biglietto in stato Implementato è possibile assegnare un revisore e solo i biglietti recensiti avanzeranno al QA.
Ho solo l'esperienza delle revisioni del codice, quindi non posso dire quanto sia bello.
Stavo lavorando con un piccolo (~ 10-15) gruppo di programmatori e stavamo usando VS Team Foundation Studio. Ci è stato chiesto di eseguire il commit del codice circa una volta al giorno e prima che ogni codice di commit fosse esaminato da qualcun altro nel gruppo (si spera che anche qualcuno coinvolto nel progetto). Durante il commit, anche il nome della persona è stato incluso in un campo.
Ho lavorato in un team che ha revisionato il codice di tutto ciò che è stato registrato in base alle modifiche durante un paio di recensioni a settimana. Ciò significa che non siamo sempre stati aggiornati con le revisioni del codice, ma ha raggiunto ciò che ci eravamo prefissati di ottenere.
Quindi, prima di tutto, chiedi cosa vuoi ottenere rivedendo il codice. Nel nostro caso, non era per catturare gli sviluppatori idioti, c'era un'assunzione di competenza piuttosto che un'assunzione di incompetenza. Ha permesso al team di avere una visione d'insieme di altre aree del sistema e ha permesso di correggere alcune discutibili decisioni di progettazione prima che fossero messe in pietra. Con ogni dubbio, intendo dire che c'è sempre più di un modo per scuoiare un gatto, e non tutti sanno che c'è già un coltello da scuoiatura nella cassetta degli attrezzi, per così dire.
Il modo in cui abbiamo affrontato le revisioni del codice è stato che ogni attività del nostro software di monitoraggio del progetto è stata rivista. All'epoca usavamo Mantis e SVN. I nostri impegni di progetto sono stati collegati in entrambi i sistemi. Ogni impegno doveva essere legato a un compito in mantide. Una volta completata l'attività, è stato assegnato lo stato "Pronto per la revisione".
Gli articoli RFR venivano quindi ritirati da chiunque avesse del tempo libero per le recensioni o fosse assegnato a una persona specifica per la revisione. Di venerdì tutti gli articoli RFR dovevano essere rivisti prima della fine della giornata in modo che non ci fossero riporti alla settimana successiva.
Gli unici problemi che abbiamo riscontrato in questo processo sono stati gli elementi di grandi dimensioni che avevano un sacco di file. Per gestire ciò, il codificatore e il revisore si sarebbero riuniti e il codificatore avrebbe eseguito le modifiche fino a quando il revisore le avesse comprese. Farebbero la revisione del codice insieme.
Questo processo si è interrotto quando la direzione ha stabilito che se la programmazione peer fosse stata eseguita, una revisione separata del codice non era necessaria. Gli sviluppatori sono diventati indecisi sul processo e hanno iniziato a essere introdotti piccoli stupidi bug. Alla fine siamo tornati al processo originale e le cose sono tornate insieme.
Nel mio team abbiamo usato una pratica per l'anno scorso 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 funzione chiamata Scaffalature. Con le scaffalature, posso "accantonare" le mie modifiche per un problema particolare. Sono memorizzati nel sistema di controllo della versione ma non sono 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 con le revisioni più recenti. Può anche "smontare" sulla sua macchina locale se vuole provare i miei cambiamenti. Quando ha completato la recensione, mi fa sapere. Quindi controllo il mio codice con "Review by Bob" alla fine del commento.
Questo ha funzionato davvero bene per noi. Innanzitutto, le revisioni 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 alcuna difficoltà importante anche se il nostro team è geograficamente diffuso, il che è molto importante. E funziona benissimo.