Facevamo le revisioni manuali del codice (cioè senza strumenti speciali) e questo era il metodo migliore che abbiamo trovato. Il nostro dipartimento di sviluppo non dispone di un server di team di fondazione, quindi non posso commentare in merito.
- Tutto il lavoro è legato a un bug o una storia agile che ha un ID univoco. Quando il lavoro è archiviato (o accantonato, che è l'invio senza check in effettivo), la descrizione avrà sempre questo identificativo.
- In uno stand-up o tramite e-mail, il revisore verrebbe informato che il bug ### o story ### è pronto per la revisione.
- Esse fanno il controllo del codice diff tra nuove versioni dei file e versioni precedenti e copia / incolla l'output di diff in un documento word. Abbiamo un modello di documento di word review in codice che è preimpostato per l'uso e ha 2 livelli di intestazioni: livello 1-modulo, livello 2-nome file. Definisce anche lo stile di formattazione per il codice effettivo (8pt Consolas). Questo passaggio è stato ovviamente il più grande, ma con il modello di Word e la sequenza Ctrl-A, Ctrl-C, Ctrl-V, non sono così tanti clic.
- Ora che il documento è in parola, il revisore può evidenziare il codice in questione e aggiungere commenti utilizzando il sistema di revisione di Word.
- Tutti i documenti sono archiviati in un repository di documenti ed etichettati con il relativo bug o numero di storia.
- Una volta terminato il documento, il collegamento al repository viene condiviso con lo sviluppatore originale. Poi avremmo una riunione di revisione del codice se le modifiche fossero abbastanza significative e dovessero essere discusse, o semplicemente lasceremo che lo sviluppatore originale passi i commenti nel suo tempo.
Dopo aver provato numerosi metodi manuali, questo è stato quello che abbiamo riscontrato per avere il minimo sovraccarico, consentendoci di rivedere effettivamente ogni cambiamento.
Tuttavia, il nostro team di ingegneri ha appena implementato Review Board e sebbene non l'abbia ancora usato molto finora, finora Sto amando ciò che ho visto. Ha tutta la flessibilità dei nostri documenti di parole, ma non copia / incolla e aggiusta manualmente la formattazione. Come bonus aggiuntivo mantiene un archivio permanente di tutti i commenti in modo da poter tornare indietro di anni se mai ne hai bisogno. Inoltre ti permette di fare diffs di diffs, il che è fantastico quando vuoi fare una revisione di una recensione del codice. Questa parte si è rivelata molto difficile con le procedure manuali perché non è possibile visualizzare ciò che è stato modificato in risposta alla prima revisione del codice, ma si finisce per ripetere l'intera operazione.
Anche se hai detto che non vuoi usare gli strumenti, ti consiglio vivamente di prendere in considerazione Review Board. È open source e completamente gratuito. Così puoi implementarlo per te stesso e per le 5 persone con cui forse lavori. Il resto della tua azienda non deve usare questo strumento se non lo desidera. E non devi preoccuparti di ottenere approvazioni di acquisto.
== Aggiornamento ai commenti dalla domanda: ==
Nel mio team, abbiamo persone a New York, CT, Texas, Polonia e India. Ciò che rende le cose ancora più interessanti è che una percentuale estremamente elevata della squadra non conosce bene il prodotto o la tecnologia, quindi pochi di noi fanno la maggior parte della recensione. Quindi sì, gli sviluppatori senior sono decisamente occupati. Nel processo che ho delineato, il revisore principale avrebbe fatto una prima analisi del codice in modo indipendente secondo il proprio programma. Ma in seguito pianifichiamo un incontro e il revisore principale guida il programmatore attraverso i suoi commenti. L'incontro può avere altri revisori, ma sono considerati secondari e non sono obbligati (ma non scoraggiati) a esaminare ogni file o fare commenti.
Sono d'accordo con gli altri commenti sul fatto che avere l'incontro finale in tempo reale, anche se devi usare la conferenza web è molto meglio per il trasferimento di conoscenza e per aiutare i tuoi nuovi ragazzi a capire il codice in modo che possano iniziare a produrre cose che rendere i tuoi sviluppatori senior ancora più impegnati. Ma ancora una volta, ciò dipende dal volume e dal tipo di commenti, a volte i commenti (molto raramente) sono così piccoli che la riunione viene saltata.
Posso anche relazionarti con te quando dici che è difficile implementare nuovi strumenti. Lavoro per una grande azienda e in genere ci sono così tante persone coinvolte che, anche al di fuori del fatto che nessun acquisto viene mai approvato, ci sono così tanti interessi / programmi che nulla è mai stato concordato. La cosa bella di Review Board è che puoi saltare tutto ciò e iniziare a utilizzare con il tuo piccolo team e se devi (se si tratta davvero di quello), puoi ospitare i servizi web sulla tua macchina di sviluppo.