Utilizzo di monitoraggi commit come modulo di revisione del codice

Question

Sto lavorando in una piccola azienda: quattro sviluppatori, che lavorano su una varietà di progetti. Abbiamo esaminato cosa possiamo fare come metodi efficaci per il miglioramento dei processi e ne è venuta un'idea.

Dato ciò che facciamo, spesso abbiamo sviluppatori singoli che lavorano su parti di un sistema, indipendentemente dagli altri sviluppatori. Questo può avere un certo numero di effetti negativi:

1. Uno sviluppatore potrebbe non essere pienamente consapevole del contesto in cui è stato attuato un cambiamento, e fare il cambiamento in modo tale da soddisfare le esigenze del cliente in corso, ma la volontà rompere le funzionalità che dipendono da altri clienti.
2. Uno sviluppatore potrebbe apportare una modifica che interrompe la progettazione architettonica attuale, introducendo una dipendenza che causerà problemi nello sviluppo futuro.
   3. Altri sviluppatori potrebbero non essere a conoscenza di come il sistema è stato modificato, in aree su cui non hanno lavorato.

Abbiamo parlato di fare le revisioni del codice, come un modo di trattare questi temi. Ma non abbiamo avuto molto successo quando ci abbiamo provato. Ci vuole un sacco di tempo per preparare una modifica per una revisione del codice, e ci vogliono tutti fuori produzione mentre la revisione viene eseguita. E i benefici di qualsiasi recensione che abbiamo provato sono stati minimi.

Stiamo utilizzando Subversion (con TortioseSVN) come VCS. Ho esaminato lo strumento CommitMonitor di SubVersion e mi sono chiesto se potesse funzionare come una sorta di revisione del codice di un uomo povero. Elenca ogni commit effettuato sul repository, consentendo a qualcuno di vedere le modifiche che sono state apportate, i messaggi di log creati per quella modifica, i file che sono stati inclusi nella modifica e le linee specifiche in ogni file che sono stati modificati.

Piuttosto che pianificare una riunione, cercando di riunire tutti per esaminare ogni cambiamento, potremmo semplicemente fare in modo che ogni sviluppatore riveda i commit di ogni altro sviluppatore, in qualunque momento fosse conveniente. Ciò manterrebbe tutti gli sviluppatori al passo con le modifiche apportate altrove nel sistema e sottoporrà a revisione ogni cambiamento per i conflitti dei clienti e l'uniformità del progetto, a un costo relativamente basso.

Se qualcuno ha riscontrato un problema con il codice che è stato archiviato, potrebbe discuterlo con lo sviluppatore che ha eseguito il commit o, più probabilmente, pianificare una riunione per discutere come la nuova funzionalità potrebbe essere implementata in un modo che non avrebbe alcun impatto sugli altri utenti o rovinare l'architettura.

Chiunque altro fa qualcosa del genere, utilizza monitor di commit per tale scopo?

Answer 1

No. Ma posso darti alcuni suggerimenti su come rendere più semplici le revisioni del codice.

1. Rendilo piccolo. Avere una regola di casa per assicurarsi che il codice viene controllato utilizzando blocchi di dimensioni ridotte, che possono essere rivisti in modo rapido e semplice. Osservando una richiesta di revisione di un set di oltre 20 file di oltre 1000 linee, i miei occhi sanguinano.
2. Fai breve. Nessuna recensione dovrebbe richiedere più di 1 ora. La messa a fuoco diventa sfocata e altri sviluppatori si risentono nel dover programmare una riunione di più ore per esaminare il codice.

Mantenere le revisioni del design su larga scala fuori dalla foto. Una revisione del codice non è il momento di dire: "Oh, amico, dovresti usare API XYZ e design pattern AwesomeFactory."

Ho avuto un'esperienza straordinaria con lo strumento di Atlassian per le revisioni online del codice - Crucible. Purtroppo non offrono una versione da $ 10" piccolo team "di questo strumento, ma dovresti comunque considerarlo per le loro funzionalità - offline CR con thread di discussione su righe di codice (e altre chicche)

Answer 2

La revisione del codice non deve essere eseguita da tutti gli sviluppatori per ogni modifica al fine di avere successo. Soprattutto se ogni revisione del codice è una riunione completa

Esistono strumenti di revisione del codice che possono essere utilizzati: ReviewBoard, che è open source, ma ce ne sono altri validi, entrambi gratuiti d commerciale.

Sembra che il modello che stai cercando sia una recensione post-commit, che è una revisione del codice dopo che è stato eseguito il commit. Puoi chiedere una recensione da una persona specifica o da tutto il team, se necessario.

Nel nostro team, preferiamo le recensioni pre-commit, tranne in caso di commit di emergenza. Nel messaggio di commit in SVN aggiungiamo un collegamento alla fine ("Revisionato da [revisore] ([link-to-reviewboard])"). Questo ci consente di collegare le recensioni ai commit.

Answer 3

ci vuole un sacco di tempo per preparare un cambiamento per una revisione del codice

Perché? Una modifica che richiede la preparazione per una revisione del codice non è pronta per il check-in.

Per eseguire la revisione, è necessario un solo sviluppatore. Avresti bisogno dell'intero team meeting solo quando emergono visualizzazioni contrastanti, in modo che il gruppo possa unificarsi attorno a una vista comune.