Come introdurre gradualmente le revisioni del codice?

25

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

C'è un buon modo per introdurre recensioni? Sento una grande riluttanza dal team, perché è solo un'altra cosa da fare e le conversazioni possono diventare dolorose. Mi sento come rivedere ogni cambiamento è un non-starter, almeno come primo passo. Mi piacerebbe che le persone entrassero nel ritmo e nella pratica di fare recensioni con alcune basse frequenze prima di aumentare la quantità.

Qualcuno ha introdotto con successo le recensioni del codice gradualmente? Come? Ho pensato di richiedere recensioni su file o librerie "hot". O scegliere a caso. O io che scelgo "choice" devo rivedere le modifiche. O sta facendo il grande passo e facendo ogni cambiamento l'unica strada da percorrere?

    
posta Philip 19.08.2016 - 01:53
fonte

5 risposte

15

Questo non è un problema di strumenti o processi. Si tratta di cultura. Descrivi una squadra composta da persone sensibili alle critiche e protettive nei confronti del proprio lavoro. È molto, molto comune. Ma non è professionale.

Il mio consiglio è di iniziare dando l'esempio. Offri i tuoi impegni per la revisione. Siate aperti sulla richiesta che le persone mettano in evidenza i problemi nel vostro approccio. Sii ricettivo al feedback. Non essere sulla difensiva, ma piuttosto esplorare le ragioni dietro il feedback & concordare 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 difficile.

    
risposta data 19.08.2016 - 02:56
fonte
38

Il primo passo sarebbe quello di andare da qualcuno e dire "hey, rivedere 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 qualche successo, fate rapporto al team.

Una volta che hai trovato qualcuno che rivede il tuo codice, chiedi se gli dispiace se rivedi alcuni dei loro codice. Definiscilo come un'opportunità di apprendimento per tu e non come un'opportunità per loro per migliorare il loro codice.

    
risposta data 19.08.2016 - 02:56
fonte
4

Is there a good way to introduce reviews?

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

  • spiega cosa ti aspetti: questa è una nuova procedura per il tuo team, o almeno una modifica al processo esistente, quindi è giusto che il team sappia perché sei istituendo il cambiamento, in che modo ti aspetti che il team ne tragga beneficio e in che modo saprai se funziona.

  • definisci il processo: fai in modo che le persone seguano il processo che desideri seguire per rivedere il codice, discutere le modifiche, ecc. in modo che tutti i membri del team sappiano come per procedere.

  • definisce i criteri: esponi i tipi di modifiche che le persone dovrebbero e non dovrebbero chiamare come se avessero bisogno di miglioramenti. Ad esempio, bug e miglioramenti significativi delle prestazioni sono buoni da segnalare; gli standard di codifica, la leggibilità e i problemi di manutenibilità dovrebbero essere annotati ma non soffermati su; le questioni relative al gusto personale o allo stile dovrebbero essere lasciate in pace.

  • discutere del comportamento: Fai notare che l'obiettivo è migliorare il codice e promuovere una comprensione comune che aiuterà il team a scrivere un 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. La definizione di alcune regole di base può aiutare ad alleviare i problemi relativi alla revisione del codice.

  • per prima cosa mettiti in prima fila: Sia che tu abbia intenzione di avere recensioni individuali o recensioni di gruppo, è probabilmente una buona idea esaminare 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 esaminarlo da solo.

Inizia tenendo una riunione preliminare per spiegare tutto quanto sopra e rispondere alle preoccupazioni dei membri del team. Follow-up con e-mail che documenta il processo.

I sense a large reluctance from the team, because it's just one more thing to do, and conversations can get painful.

Queste sono due preoccupazioni distinte. Se ritieni che le recensioni possano essere utili, è necessario dedicare del tempo al programma per eseguirle. Assicurati che i membri del team capiscano che la revisione è come qualsiasi altra attività, non qualcosa di aggiuntivo che devono fare continuando a completare altre attività con la stessa velocità.

Le riunioni di revisione del gruppo dovrebbero essere guidate da un facilitatore che mantenga la discussione in movimento, limiti la durata della riunione e mantenga le cose costruttive. Questo dovrebbe fare molto per evitare conversazioni dolorose. Nel momento in cui sarai pronto per iniziare le singole revisioni, il team sperabilmente avrà adottato comportamenti che li aiutino a mantenere le cose costruttive da soli.

Dovresti anche rivedere il processo di revisione di volta in volta. Riunisci il team ogni tanto per discutere del processo: come funziona, come potrebbe essere migliorato, quali pratiche dovrebbero essere abbandonate, ecc. Assegna al team il processo e la libertà di provare nuove cose.

    
risposta data 20.08.2016 - 00:24
fonte
3

Come guida di una squadra, il maggior valore che ottengo dal processo di revisione del codice è consapevolezza di ciò che sta accadendo. Mi piace avere la possibilità di vedere ogni changeset, anche se non ho modifiche o suggerimenti per lo sviluppatore. Io chiamo queste "recensioni sulla consapevolezza". Posso girarli in meno di 30 minuti, quindi non c'è il collo di bottiglia.

Ti suggerirei di iniziare con quelli. Definisci il processo di invio della revisione del codice (è abbastanza tagliato e asciugato se usi TFS) e invita tutti a inviare i loro changeset a te (e solo tu) prima di effettuare il check-in. Dì loro che è solo per consapevolezza e nessuno sta per criticare il loro codice.

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

Una volta che hai impegnato tutto il team, probabilmente scoprirai che i tuoi sviluppatori non riescono a fare suggerimenti sul codice degli altri. Accadrà in modo naturale e organico (gli ingegneri non possono aiutare se stessi!) Far incontrare il team per discuterne e formulare le linee guida per offrire feedback costruttivi l'uno all'altro. Quindi impostali. Congratulazioni, ora sei in modalità completa di revisione del codice!

    
risposta data 19.08.2016 - 22:33
fonte
-2

Un modo per farlo è condurre sessioni di revisione del codice dopo ogni sprint e passare attraverso tutte le modifiche in cui il codice viene proiettato su una sorta di grande schermo in modo che tutti i membri del team possano partecipare. Qualsiasi miglioramento può essere aggiunto come debito tecnico all'arretrato.

Questo approccio funziona, ma non è perfetto.

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

    
risposta data 19.08.2016 - 03:02
fonte

Leggi altre domande sui tag