Come introdurre gradualmente le revisioni del codice?

Sono a capo di una squadra con una mezza dozzina di ingegneri senior. Credo fermamente che ci trarrebbe un grande vantaggio fare revisioni del codice per tutti i motivi standard. Non necessariamente ogni cambiamento, ma almeno un flusso costante di recensioni di fondo. Quindi le persone almeno vedono i cambiamenti degli altri e iniziano a parlarne.

C'è un buon modo per presentare recensioni? Sento una grande riluttanza da parte del team, perché è solo un'altra cosa da fare e le conversazioni possono diventare dolorose. Sento che rivedere ogni modifica non è un inizio, almeno come primo passo. Vorrei che le persone prendessero il ritmo e la pratica di fare recensioni con una bassa frequenza prima di aumentare la quantità.

Qualcuno ha introdotto con successo recensioni di codice gradualmente? Come? Ho pensato di richiedere recensioni su file o librerie "caldi". O scegliere a caso. Oppure scelgo le modifiche "scelte" da rivedere. O fare il grande passo e fare ogni cambiamento è l'unica strada da percorrere?

Questo non è un problema di utensili o processo. Riguarda la cultura. Descrivi una squadra composta da persone sensibili alle critiche e protettive del proprio lavoro. È molto, molto comune. Ma non è professionale.

Il mio consiglio è di iniziare a dare l'esempio. Offri i tuoi impegni per la revisione. Siate aperti nel chiedere alle persone di evidenziare i problemi nel vostro approccio. Sii ricettivo al feedback. Non essere difensivo, ma esplora invece i motivi alla base del feedback e concorda le azioni come una squadra. Incoraggiare un'atmosfera di dialogo aperto. Trova un campione o due nella tua squadra che sono disposti a fare anche questo.

È un lavoro duro.

Il primo passo sarebbe avvicinarsi a qualcuno e dire "ehi, rivedresti il ​​mio codice?". Sii il cambiamento che vuoi vedere nella tua organizzazione. Se non riesci a trovare un singolo individuo disposto a farlo, non sarai in grado di convincere l'intera squadra. Se voi due avete successo, riferite alla squadra.

Una volta trovato qualcuno per rivedere il tuo codice, chiedi se gli dispiace se rivedi parte del suo codice. Frase come un'opportunità di apprendimento per te e non come un'opportunità per loro di migliorare il loro codice.

Come team leader, il massimo valore che ottengo dal processo di revisione del codice è la consapevolezza di ciò che sta succedendo. Mi piace avere la possibilità di vedere tutti i cambiamenti, anche se non ho cambiamenti o suggerimenti per lo sviluppatore. Chiamo queste "recensioni di consapevolezza". Posso girarli in meno di 30 minuti, quindi non ci sono colli di bottiglia.

Vorrei suggerire di iniziare con quelli. Definisci il processo di invio della revisione del codice (è abbastanza semplice se utilizzi TFS) e coinvolgi tutti gli utenti a inviarti i loro changeset (e solo tu) prima del check-in. Di 'loro che è solo per consapevolezza e nessuno criticherà il loro codice.

Dopo un'iterazione o due di revisioni della consapevolezza, inizia a invitare altri membri del team a rivedere il codice a vicenda ... di nuovo, solo per consapevolezza. Che ci crediate o no, questo da solo può essere utile per la coesione del team e l'uniformità del codice.

Una volta che avrai coinvolto l'intero team, probabilmente scoprirai che i tuoi sviluppatori non riescono a resistere nel dare suggerimenti sul codice degli altri. Accadrà in modo naturale e organico (gli ingegneri non possono fare a meno di se stessi!) Chiedi al team di incontrarsi per discuterne e elaborare linee guida per offrire un feedback costruttivo reciproco. Quindi impostali su di esso. Congratulazioni, ora sei in modalità di revisione del codice completo!

C'è un buon modo per presentare recensioni?

Probabilmente ci sono molti buoni modi, a seconda del tuo team e dei vantaggi che speri di ottenere dalle recensioni, ma qualsiasi approccio avrà alcune caratteristiche comuni:

• spiega cosa ti aspetti: questo è un nuovo processo per il tuo team, o almeno una modifica al processo esistente, quindi è giusto far sapere al team perché stai introducendo il cambiamento, come ti aspetti che il team ne tragga beneficio e come saprai se funziona.

• definire il processo: accompagnare le persone attraverso il processo che si desidera seguire per rivedere il codice, discutere le modifiche, ecc., in modo che tutti i membri del team sappiano come procedere.

• definire i criteri: definire i tipi di cambiamenti che le persone dovrebbero e non dovrebbero chiamare come bisognosi di miglioramento. Ad esempio, è bene sottolineare bug e significativi miglioramenti delle prestazioni; gli standard di codifica, la leggibilità e i problemi di manutenibilità dovrebbero essere annotati ma non approfonditi; questioni di gusto o stile personale dovrebbero essere lasciate sole.

• discutere del comportamento: sottolinea che l'obiettivo è migliorare il codice e favorire una comprensione comune che aiuterà la squadra a scrivere codice migliore su tutta la linea, non a mettere in imbarazzo nessuno, a sistemare i punteggi, ecc. Le critiche dovrebbero essere obiettive e costruttive, mai personali. Stabilire alcune regole di base può aiutare ad alleggerire la revisione del codice.

• mettiti al primo posto: se hai intenzione di avere recensioni individuali o recensioni di gruppo, è probabilmente una buona idea passare in rassegna i primi come gruppo. La prima recensione dovrebbe essere del tuo codice in modo che gli altri membri del team possano vedere che il processo non è così male e che sei disposto a seguirlo da solo.

Inizia tenendo una riunione preliminare per spiegare tutto quanto sopra e rispondere alle preoccupazioni dei membri del team. Seguire con la posta elettronica che documenta il processo.

Sento una grande riluttanza da parte del team, perché è solo un'altra cosa da fare e le conversazioni possono diventare dolorose.

Queste sono due preoccupazioni distinte. Se ritieni che le recensioni possano essere utili, devi fare un po 'di tempo nel programma per farle. Assicurati che i membri del team comprendano che la revisione è un lavoro come qualsiasi altra attività, non qualcosa di aggiuntivo che devono fare mentre continuano a completare altre attività alla stessa velocità.

Le riunioni di revisione di gruppo dovrebbero essere condotte da un facilitatore che mantiene la discussione in corso, limita la durata della riunione e mantiene le cose costruttive. Ciò dovrebbe fare molto per evitare conversazioni dolorose. Quando sarai pronto per iniziare le singole recensioni, il team si spera che abbia adottato comportamenti che li aiutino a mantenere le cose costruttive da sole.

È inoltre necessario rivedere periodicamente il processo di revisione. Riunisci il team ogni tanto per discutere del processo: quanto sta funzionando, come potrebbe essere migliorato, quali pratiche dovrebbero essere abbandonate, ecc. Dai al team la proprietà del processo e la libertà di provare nuove cose.

Un modo per farlo è condurre sessioni di revisione del codice dopo ogni sprint e analizzare le modifiche di tutti in cui il codice viene proiettato su una sorta di schermo di grandi dimensioni in modo che tutti i membri del team possano partecipare. Eventuali miglioramenti possono essere aggiunti come debito tecnico al portafoglio ordini.

Questo approccio funziona, ma non è perfetto.

L'obiettivo finale sarebbe quello di utilizzare la richiesta pull per unire nuovamente il codice nel master o sviluppare un ramo in cui ogni riga di codice deve essere rivista.