Chi dovrebbe fare le revisioni del codice?

Nella mia azienda l'architetto esegue principalmente recensioni di codice. È un ragazzo software molto esperto e intelligente, quindi è molto bravo a farlo. Quando gli sviluppatori eseguono le revisioni del codice, non lo fanno nemmeno per metà. Abbiamo provato a dare agli sviluppatori di fare più revisioni del codice, ma la qualità delle revisioni del codice non era buona. Usiamo Scrum per come metodologia di sviluppo.

Tuttavia con l'attuale sistema ci sono due problemi:

1. L'architetto diventa un collo di bottiglia

2. Gli sviluppatori non si assumono la responsabilità per la qualità del codice e dell'architettura (che porta a tutti i tipi di problemi).

Come possiamo affrontare questi problemi? Dovremmo cambiare chi rivede il 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. Facendo qualcun altro fare revisioni del codice, stai dicendo ai tuoi sviluppatori che non è loro responsabilità assicurarsi che il codice soddisfi gli standard aziendali.

Se ritieni che debbano essere addestrati a fare recensioni di codice, prendilo per loro. Data la tua situazione attuale, potresti fare in modo che uno sviluppatore esegua la revisione del codice e poi lo faccia commentare dal tuo architetto: chiedi allo sviluppatore di sottoporre la revisione all'architetto per l'approvazione prima di inviarla al mittente.

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

• Recensioni collaborative. Questo ha funzionato davvero alla grande nella mia ultima squadra. Abbiamo messo l'intero team in una stanza con un proiettore e abbiamo iniziato a rivedere alcuni elementi. Forse all'inizio l'architetto è quello che guida la recensione, ma in poche settimane (abbiamo prenotato una o due ore ogni venerdì) l'intero team inizia a parlare e comprendere i concetti chiave che attualmente solo l'architetto sembra conoscere.

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

Mentre vedo il punto in cui l'architetto di sistema / software annulla tutte le modifiche / i commit, gli sviluppatori di software dovrebbero essere in grado di fare recensioni senza coinvolgere l'architetto, tranne l'arbitrato.

Le mie procedure di revisione preferite [*] sono:

• Raggruppa le modifiche per requisito / problema.
• Invita tutti gli sviluppatori, l'architetto del software e l'autore del requisito / problema a rivedere. (Non sono tutti tenuti a fare una recensione.)
• Considera una recensione finita quando:
  • Due sviluppatori hanno recensito.
  • A tutti i commenti viene risposto. (Forse facendo decidere all'architetto software.)
  • È trascorso un giorno lavorativo senza ulteriori discussioni (o tutte le parti invitate hanno esaminato).

Quindi la mia breve risposta alla tua domanda è: gli sviluppatori dovrebbero cambiare le recensioni.

[*] Purtroppo non è sempre così che funzionano i progetti a cui partecipo.

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

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

Onestamente, però, sembra ridicolo avere un architetto che fa recensioni di codice. Dovrebbe fare revisioni di progettazione o revisioni occasionali di codice in modo informale per condividere la sua esperienza. Il team di ingegneri dovrebbe assumersi la responsabilità del 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à semplicemente con "Non lo so, sembra funzionare, ma lascia che quel ragazzo intelligente capisca se va bene o no". Posso pensare a quanto segue:

• rendere pubblico il codice in modo che tutti possano vedere su cosa stanno lavorando tutti; inserire i nomi all'inizio di ogni file che contiene codice; magari stampandoli e stampandoli nel bagno o dovunque tu senta che attireranno alcuni occhi
• programmazione in coppia; con un altro cervello accanto a te, ci penserai due volte prima di nominare la tua variabilei
• raccogli il tuo bidello e spiegagli come funziona quell'eredità (oh, sì, non funziona). Spiegare il tuo codice a qualcun altro aiuta. Forse si compila, forse fa le cose giuste, ma non hai davvero capito il perché. Adesso è 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