Come si costruisce una cultura del code review? Le mie osservazioni in dieci anni

concordo sulla regola dei piccoli blocchi ma in pratica è dura. a volte la modifica è grande per natura.

da noi la soluzione è stata questa: prima di inviare la modifica grande, scriviamo e condividiamo l'approccio in una pagina. cinque minuti di lettura evitano un'ora di discussione sulla review.

scoprire che l'approccio è sbagliato dopo aver scritto 500 righe è la cosa peggiore. a quel punto nessuno vuole tornare indietro e la decisione pessima va in produzione.

Posso dire una cosa da principiante?

Per me la parte più difficile non è non prendere i commenti sul personale. Quando arriva un commento che non capisco, esito a chiedere di nuovo, penso di sembrare stupido. Poi correggo a intuito e sbaglio.

Non so se succede solo a me, ma forse capita anche ad altri.

Non succede solo a te, è molto comune ed è compito nostro correggerlo, non tuo.

Da noi hanno funzionato due cose. La prima: quando scrivi un commento, scrivi anche la motivazione. Invece di "cambia qui", dire "dà errore in questa situazione, quindi è meglio così". Se c'è la motivazione, il bisogno di fare domande diminuisce.

La seconda: quando ci sono più di due round di messaggi, portare la conversazione in chat. Una call di quindici minuti è più veloce di quindici commenti e molto meno logorante.

E poi vi dico una cosa: non esistono domande stupide. Altre tre persone nel team si chiedono la stessa cosa che chiedi tu, ma non domandano. Facendo la domanda, fai un favore a tutte e quattro.

Lasciare le discussioni di stile agli strumenti è da sola il guadagno maggiore. Si configura in una settimana, fa risparmiare tempo per anni.

Un avviso da parte del project management: inserite la durata della review nel piano.

Da noi è andata così: per un bel po' non abbiamo considerato la code review parte del lavoro, nel piano c'era solo il tempo di sviluppo. Risultato: ogni review veniva vista e fatta come "quella cosa che ritarda tutto", giusto per finta.

Da quando l'abbiamo messa nel piano, nessuno sabota più le review, perché ormai non è più un ritardo, è parte del piano stesso.

Ho vissuto la stessa cosa.

Esattamente così. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Lascio una nota potrebbe servire.

Concordo pienamente. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Se avete domande, scrivete, rispondo per quanto possibile.

A me è successo l'esatto contrario per questo scrivo. Il vero problema non è il numero, ma su cosa si basa quel numero.

Se scrivete qui il risultato, sarà utile anche ad altri.

Lascio un avvertimento. Quando prendi una decisione, guarda prima quali dati hai a disposizione.

Nessun processo migliora senza tracciamento perché non sai cosa correggere. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Ti seguo.

Anche da noi è così.

Salvato.

Riassumo l'argomento, perché sono state date diverse risposte. Inizia con un piccolo test non impegnarti subito su tutto.

Io seguirei questa strada.

Scusate, ma questo non vale in ogni caso. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Correggetemi se sbaglio.

Raro trovare articoli che spiegano le cose così chiaramente. Non abbiate paura di chiedere, chi non chiede paga sempre di più.

Se lo scope cresce devono crescere o i tempi o il budget. Non c'è una terza opzione. Sono curioso di sapere se qualcuno lo fa in modo diverso.

argometno molto attuale.

Preso nota, grazie.