Se il tuo team esegue la revisione del codice, in che misura verifichi che vengano eseguite le correzioni di revisione? [chiuso]

La chiave del successo (se ce n'è una) è di farlo come piace alla squadra. Sono stato in team in cui nulla si impegna a VCS prima revisione del codice, seguito da un'altra recensione se c'era qualcosa da risolvere. Questo andava bene per il team visto che tutti avevano accettato di farlo, era considerato prezioso e non troppo rigoroso.

In alcune altre squadre, questo sicuramente non avrebbe funzionato. Ad esempio, in un altro team abbiamo avuto membri di organizzazioni diverse, con competenze diverse. Anche con uno stile di recensione molto più leggero abbiamo avuto problemi con persone che hanno paura di fare recensioni o "essere" riviste. Ovviamente ci sono più di una spiegazione per questo "fallimento", ma IMO, la più grande è la mancanza di "buy in": le persone avevano background e aspettative troppo diverse, forse mancanza di fiducia, per essere in grado di utilizzare efficacemente le revisioni del codice. In queste squadre, le revisioni del codice forse non sono state affatto vantaggiose.

Il team deve decidere se eseguire le revisioni del codice e, in caso affermativo, come. Inizia con qualcosa su cui tutti i membri del team possono essere d'accordo. Nel tempo, le abitudini e i gusti cambieranno. Quindi è il momento di adattarsi di nuovo.

La nostra procedura di revisione del codice richiede l'approvazione del revisore. Se le modifiche che consigliano dopo la discussione non vengono apportate, non si disconnettono.

Il tuo team si spera che sia composto da professionisti che possono e faranno il lavoro che sono stati pagati per fare. Approfitto di tutto per non trattarli come bambini controllandoli e facendo in modo che stiano facendo quello che dovrebbero.

Le revisioni del codice sono fatte alla nostra scrivania e tutti i partecipanti prendono appunti da portare alla riunione. L'incontro non dovrebbe durare più di mezz'ora. Qualcuno impiega alcuni minuti e invierà a tutti un'email a tutti gli elementi di azione per quella riunione. Quei suggerimenti per la revisione del codice che sono stati concordati ora sono attività sul piano sprint.

Se queste attività non vengono soddisfatte, lo sviluppatore deve spiegare perché. A quel punto non è necessario "ricontrollarlo" per assicurarsi che abbia fatto quel lavoro.

IMHO se hai bisogno di "ricontrollare" le attività degli sviluppatori completate, il tuo team ha una grave carenza di competenze, carenza etica o entrambe e dovrebbe essere corretto a un livello più alto.

Ho visto entrambe le pratiche e in generale riflette le esigenze di qualità delle diverse organizzazioni.

Nell'ambiente in cui la qualità era essenziale, ai problemi sollevati veniva assegnata una severità. Lo sviluppatore senior responsabile della revisione controllerebbe le modifiche apportate e approverà il risultato (o raccomanderà un'altra revisione, se le modifiche fossero troppo complesse).

In un altro ambiente potremmo semplicemente fidarci degli sviluppatori. I problemi sollevati durante la revisione del codice erano generalmente formulati come consigli comunque e spesso era ragionevole ignorarli. Quando le scadenze sono strette, alcuni miglioramenti non pagano solo dal punto di vista del business.

Facciamo revisioni del codice per il 100% del nostro codice.

Usiamo Fisheye che abbiamo legato nel nostro sistema di tracciamento dei biglietti, Jira

• I revisori vengono aggiunti a un ticket in modo che possano riesaminare il codice.
• Esaminano e commentano in Fisheye
• Lo sviluppatore apporta le modifiche manualmente come indicato, a volte dopo una discussione online o di persona.
• È possibile che vengano effettuati ulteriori "round" di recensioni a seconda delle modifiche apportate dopo le recensioni.

Finalmente la recensione è chiusa. Non esiste un "passaggio" specifico per assicurarsi che le modifiche siano state applicate. Invece ci affidiamo al fatto che siamo professionisti, siamo artigiani, ci preoccupiamo del nostro codice. Preferisco questo approccio "professionale" alle rigide regole procedurali che le persone hanno paura di rompere. Se un revisore ha fatto un suggerimento e l'abbiamo ignorato, di solito si presenterà presto in un altro contesto.

Tuttavia questo approccio implica:

• professionisti che rispettano l'un l'altro
• ottima comunicazione
• accordo sugli standard

In realtà una buona comunicazione include molti fattori come:

• layout fisico. i membri del gruppo che non si trovano nell'area principale sono un problema frequente
• mischia e mischia di mischia (per passare informazioni con altre squadre)
• retrospettive - per assicurarti che il processo funzioni per tutti

Accordo sugli standard significa:

• comprensione formale scritta o orale delle pratiche da utilizzare
• sistemi che si adattano al cambiamento
• sviluppatori che parlano delle differenze e cercano un accordo
• retrospettiva su retrospettive - per esaminare il nostro processo agile stesso.

Nel mio team viviamo, le revisioni dei codici di stile per la paia di coppie. Le correzioni vengono spesso eseguite al volo mentre si discutono i possibili miglioramenti che possono essere apportati. Abbiamo scoperto che la comunicazione diretta avviene per creare un tipo di contratto tra il revisore e il revisore, in modo che le correzioni siano più probabili e ci sono meno problemi che se usassimo uno strumento o un documento come un buffer tra i due.

Solo la traccia scritta che abbiamo è che menzioniamo il revisore nel controllo del codice sorgente durante il commit, il che rende più facile tracciare quali commit del codice sono stati o non sono stati revisionati.

Le recensioni di codice sono integrate nel nostro SDLC.

1. A uno sviluppatore viene assegnato un compito.
Il codice
2. viene controllato in Controllo origine, associato a tale attività.
3. Una volta che tutto il codice è pronto, l'attività è contrassegnata per la revisione.
4. Se Review non riesce, gli sviluppatori correggono il codice sotto la stessa attività. GOTO 4.
5. Se Review passa, il codice viene promosso nell'ambiente di integrazione (Alpha).

Controlliamo il codice in base ai nostri standard di codifica e cerchiamo qualsiasi cosa che possa avere un impatto negativo sulle prestazioni.

I revisori del mio codice hanno gusti diversi, ma per lo più ottengo il timbro di gomma. Alcuni recensori di codice sembrano volere il processo il più rapidamente possibile, al punto che ho chiesto al mio team leader per uno e la sua risposta è stata "si, va bene, basta mettere il mio nome in basso", senza effettivamente guardare il codice .

C'è un appaltatore che può revisionare il mio codice (che attualmente sta lavorando allo stesso progetto), e darà un feedback occasionale ma non produrrà mai commenti. Ho l'impressione che non sia eccessivamente preoccupato per il codice base finché il risultato sembra funzionare. Ho dovuto iniziare a segnalare le scorciatoie che stava prendendo, che non è una situazione in cui voglio essere.

Gli altri due team leader sono più accurati: controllano ogni file, mi dicono di cambiare le cose, di dare consigli e un buon feedback. Ancora nessuna documentazione viene prodotta, a parte il loro nome che va contro il commit.

Gli svantaggi dei revisori decenti sono che le sessioni durano più a lungo e sento che il mio capo squadra potrebbe sentirsi offeso se smetto di chiedergli recensioni. Penso che le nostre recensioni del codice sarebbero migliori senza il presente del recensore e fatte al lusso del recensore.

Il sistema di Adrian sembra buono, ma dubito che la gestione sarebbe andata avanti a causa del tempo extra che ci sarebbe voluto.