Chi dovrebbe fare recensioni di codice?

Gli sviluppatori dovrebbero fare revisioni del codice. Dovrebbero fare revisioni del codice, perché dovrebbero conoscere il codice, gli standard e le pratiche di stile dell'azienda. Avendo qualcun altro fare recensioni di codice, stai dicendo ai tuoi sviluppatori che non è loro responsabilità assicurarti che il codice soddisfi gli standard aziendali.

Se pensi che abbiano bisogno di formazione per fare revisioni del codice, prendilo per loro. Data la tua situazione attuale, potresti fare una revisione del codice da parte di un dev, e poi farla commentare dal tuo architetto - chiedi all'ente di revisione di sottoporla a revisione per l'approvazione prima di inviarla al mittente.

In questa situazione, ciò di cui hai bisogno è la conoscenza di questo esperto sviluppatore per aiutare il resto del team a crescere. La qualità di una squadra non è definita dalle abilità del miglior sviluppatore; è definito dalle abilità del peggio. Puoi provare cose come:

• Recensioni di collaborazione. Questo ha funzionato davvero bene nella mia ultima squadra. Abbiamo messo l'intera squadra in una stanza con un proiettore e abbiamo iniziato a recensire alcuni elementi. Forse all'inizio l'architetto è quello che guida la recensione, ma in poche settimane (abbiamo riservato una o due ore ogni venerdì) tutta la squadra inizia a parlare e capire i concetti chiave che al momento solo l'architetto sembra sapere.

• Accoppia la programmazione. Per me questo è lo strumento migliore per diffondere la conoscenza in una squadra.

Mentre riesco a vedere il punto in cui l'architetto del sistema / del software firma tutte le modifiche / commit, gli sviluppatori software dovrebbero essere in grado di fare revisioni senza coinvolgere l'architetto - tranne per l'arbitrato.

Le mie procedure di revisione [*] preferite sono:

• Modifiche di gruppo in base al requisito / problema.
• Invita tutti gli sviluppatori, l'architetto del software e l'autore del requisito / problema da esaminare. (Non sono tutti richiesti per fare una revisione.)
• Considera una recensione terminata quando:
  • Due sviluppatori hanno esaminato.
  • A tutti i commenti viene risposto. (Probabilmente facendo decidere all'architetto del software.)
  • È trascorso un giorno lavorativo senza ulteriori discussioni (o tutte le parti invitate hanno esaminato).

Quindi la mia risposta breve alla tua domanda è: Gli sviluppatori dovrebbero fare delle revisioni.

[*] Purtroppo questo non è sempre il modo in cui i progetti a cui partecipo.

Mi piace la pratica di occasionali revisioni del codice del team che includono l'intero team degli architetti, ma poi molte, molte e molte recensioni di codice tra due o tre membri del team.

Se è davvero un codice complicato o sensibile, allora arruola l'architetto oi membri senior del team.

Onestamente, però, sembra ridicolo avere un architetto fare recensioni di codice. Dovrebbe fare revisioni del design o recensioni occasionali di codice per condividere la sua esperienza. Il team di ingegneri dovrebbe assumersi la responsabilità per il codice. Se ci sono problemi, allora miglioreranno con il tempo.

Sono d'accordo, se solo una persona fa recensioni, il resto dei ragazzi probabilmente andrà solo con "Non lo so, sembra funzionare, ma lascia che quel ragazzo intelligente capisca se va bene o no". Posso pensare a quanto segue:

• rendi pubblico il tuo codice in modo che tutti possano vedere su cosa stanno lavorando; mettere i nomi all'inizio di ogni file che contiene il codice; magari stampali e stampali nel bagno, o ovunque tu senta che prenderà degli occhi
• pair programming; con un altro cervello accanto a te, ci penserai due volte prima di nominare la tua variabile i
• prendi il tuo bidello e spiegagli come funziona quell'eredità (oh, sì, non funziona). Spiegare il tuo codice a qualcun altro aiuta. Forse compila, forse fa le cose giuste, ma non hai davvero capito il perché. Ora è la tua occasione
• avere una serie di linee guida e far sì che tutti le seguano; qualunque sia la linea guida, è meglio di nessuna linea guida