Ottenere i codificatori per fare la revisione del codice [duplicato]

La revisione del codice è una soluzione a un problema. Hai un problema e lo risolverebbe "Code Review"? Le altre persone stanno controllando il codice errato? La mia ipotesi è che siano in una certa misura, ma forse i tuoi altri programmatori non pensano che sia così male che vale la pena / il tempo di fare una recensione. Chiedi ai tuoi sviluppatori senior di trovare una soluzione per limitare la quantità di codice errato registrato nel sistema. Potrebbero trovare soluzioni più efficaci.

Risolvi il problema di avere un codice errato (la revisione del codice è uno dei pezzi del puzzle). Un modo per motivare gli sviluppatori è quello di interrompere l'aggiunta di nuove funzionalità fino a quando non vengono corretti errori / codice errato. La maggior parte degli sviluppatori preferisce creare nuove cose. Fai in modo che i senior correggano bug e refacting codice errato. Forse impareranno che è più facile prenderlo nella revisione del codice.

Ancora una volta, identifica un problema e offri ai tuoi anziani la possibilità di trovare una soluzione.

Non puoi continuare a pagare persone che non fanno quello che dici loro, quindi assicurati che queste cose siano molto importanti. Aiuta se tutti sono d'accordo che c'è un problema e contribuisce alla soluzione. Alla fine, devi renderli responsabili. Non eseguono la revisione del codice, prendono una posizione inferiore o vengono licenziati.

In futuro, assumi persone disposte a fare la revisione del codice o almeno fagli sapere che questo fa parte del lavoro in modo che possano fare una scelta informata.

Modifica se hai problemi con il tuo jr. Il codice di dev, i tuoi anziani potrebbero ritenere che la qualità sia così bassa, sarebbe più veloce riscriverlo piuttosto che passare attraverso un processo di revisione e correzione. Sarebbe importante sottolineare i benefici a lungo termine di prendersi il tempo ora di rivedere, al fine di dare un feedback agli sviluppatori junior per migliorarli in futuro.

it is easy to hire developers

Questo è il problema. Gli sviluppatori che assumete semplicemente non sono motivati o non hanno esperienza per mantenere il codebase in alta qualità. Dovresti concentrarti sull'assunzione di sviluppatori che si assumono la responsabilità di mantenere alta la qualità del codice. E trovare sviluppatori del genere è estremamente difficile. Entrambi perché non ce ne sono molti e quello che emerge dall'intervista a cui lo sviluppatore si preoccupa del codice è complicato.

Lavoravo in un'azienda che assumeva sviluppatori buoni e motivati e li manteneva. Tuttavia, ritenevamo che ci fosse un valore nella revisione del codice: aiuta a diffondere la conoscenza e solo perché una persona ritiene che quello che ha scritto sia un buon codice non significa che non ci sia spazio per miglioramenti.

E abbiamo affrontato un problema simile. I codificatori preferivano il codice. Per non parlare di voler evitare la complessa dinamica di potere di avere un peer svolgere un compito che è deliberatamente critico del tuo lavoro, per quanto ben intenzionato.

La risposta che abbiamo trovato è stata: birra .

Questo non è uno scherzo. Una volta ogni 2-3 settimane l'azienda pagava per ottenere della birra buona e passavamo le ultime 1-2 ore della settimana lavorativa facendo la revisione del codice. La birra gratis era un buon motivatore, e la convivialità generata da un lieve euforia rimuoveva gran parte del pungiglione dal processo.

Funzionava così bene che quella che era stata una cosa negativa che tutti i programmatori volevano evitare è diventata qualcosa di clou mensile: tutti abbiamo avuto bevande gratuite, un'atmosfera piacevole e abbiamo dovuto migliorare il nostro codice tutto allo stesso tempo.

Getting coders to do code review

Questo è un problema culturale e tu sei attualmente in uno stato di equilibrio perché sono abituati a non dover dare o ricevere critiche sul loro lavoro. Cambiare la cultura dall'alto -down, devi guidare, dirigere e imporre, se necessario, di mantenerlo come un'abitudine culturale.

Ti suggerisco di iniziare pianificando la recensione, chiedendo ai tuoi migliori programmatori di guidarti attraverso il loro codice, con gli altri feedback sull'offerta. Se pensi che ci sia troppa speculazione o interazione improduttiva, rimettila in carreggiata. Se vengono identificati piccoli problemi che possono essere corretti sul posto, farlo sul posto. Prendi appunti e fai domande che dimostrano che stai facendo del tuo meglio per seguirti. Tieni traccia dei problemi che sono noti con enfasi e che devono essere affrontati, cioè il debito tecnico, e fagli dedicare del tempo per affrontare specificamente le questioni relative al debito tecnico.

Potresti iniziare con un'intera panoramica architettonica, e poi su base settimanale o anche giornaliera iniziare a scavare in ogni modulo che hanno scritto. Ti consiglio di iniziare con i tuoi migliori programmatori e poi di lavorare ai tuoi sviluppatori più giovani in modo che non si sentano minacciati di aver visto gli altri accettare critiche, anche se potrebbero ricevere critiche un po 'più.

L'unico modo per ottenere un cambiamento a questo punto è assumere la proprietà del problema e guidare la modifica.

In qualsiasi piano è probabile che ci sia una certa differenza tra ciò che vorresti essere ad alta priorità e ciò che in realtà è alta priorità. Dal momento che stai pagando, puoi decidere quale è la priorità più alta e devi dire innanzitutto alle persone che stai pagando di lavorare su argomenti con priorità elevata.

Quindi, se stanno evitando la revisione del codice, allora:

• Non stai rendendo la revisione del codice una priorità più alta rispetto alla scrittura di un nuovo codice. Potresti pensare di sì, quando in realtà stai dicendo "possiamo farlo entro la fine di domani?" e lasciando che rispondano "certo, se lasciamo tutto il resto". "Tutto il resto" significa che salta la revisione del codice su questo e qualsiasi cosa abbia fatto di recente che necessita di revisione.
• Non stanno facendo ciò che hai chiesto loro e li hanno pagati per farlo. Dato che sei disposto a pagare un extra per la revisione del codice e loro ancora preferiscono scrivere un nuovo codice senza revisione per meno soldi, devi scoprire da loro perché la revisione del codice è così spiacevole.

In ogni caso, per coinvolgere gli sviluppatori, è possibile esaminare il concetto di Scrum di una "definizione di fatto". Potresti avere questo anche se non stai facendo Scrum e includere la revisione del codice nella definizione del tuo team. Cioè, non possono dire che X è finito finché X non è stato revisionato, il che significa che devono trovare qualcuno che riveda il loro codice (e il codice dei ragazzi di cui sono responsabili). Speriamo che questo porti a scambiarsi recensioni tra loro.

Un altro modo per presentarlo è che esaminando il codice si stanno familiarizzando con parti del sistema su cui potrebbe essere necessario lavorare in futuro. Se incoraggi la responsabilità condivisa per l'intera base di codice, al contrario della proprietà dei componenti, quindi imponi più occhi su ogni parte di codice. Certo, non è la stessa cosa di una fase di revisione formale, ma è una mossa nella giusta direzione poiché raggiunge lo stesso obiettivo di evitare l'uso di codice che solo una persona ritiene sia corretta.

Ovviamente se loro davvero odiano la revisione allora potrebbero scegliere di fare una recensione completamente superficiale, passando tutto più o meno senza leggerlo. In tal caso dovrai approfondire il problema e convincerli a fare un buon lavoro. Per dimostrare che la revisione è utile, è possibile indicare i problemi che si verificano a causa di qualcuno che ha perso la recensione che avrebbero dovuto fare. Si spera che i professionisti rispondano abbastanza strong una volta che i loro errori sono stati visti come causa di problemi reali, ma spesso meno intensamente se non riescono a spuntare quello che percepiscono come un compito inutile. Se non riesci a trovare problemi che possano essere almeno parzialmente ascritti alla mancanza di revisione, considera di nuovo come hai deciso che la recensione è veramente utile per questo progetto.

Un'altra possibilità, che non posso escludere da ciò che dici nella domanda, è che i programmatori che hai semplicemente non sono molto buoni, o almeno non sono molto bravi a produrre un progetto di lavoro senza ulteriori tecniche supporto. Non parli di test, bug fixing o QA in generale. Se tutto ciò che vogliono è scrivere codice e non volerlo far funzionare in modo affidabile, quindi naturalmente non fare la revisione del codice sarebbe una parte di questo. Il rovescio della medaglia, suppongo, è che forse i tuoi programmatori sono così universalmente fantastici che il loro codice funziona sempre per la prima volta e non ha bisogno di test, correzione dei bug o revisione. Sembra improbabile!

Immagino che tu abbia già deciso che fare revisioni di codice è un compito necessario se sei disposto a pagare di più gli sviluppatori senior per questo.

La maggior parte degli sviluppatori (nella mia esperienza di sviluppatore di Jr) preferirebbe sviluppare qualcosa di nuovo, piuttosto che guardare indietro sul codice che loro, o qualcun altro, hanno già fatto. Detto questo, ci sono punti extra che devono accadere o renderanno il compito particolarmente indesiderabile.

Standard di codifica . Ci dovrebbe essere una sorta di standard su come il codice viene generalmente visualizzato in modo che tutti non lo facciano in modo diverso, ovunque. Migliori standard di codifica, se seguiti, significheranno revisioni più rapide e meno dolorose. Fornisce inoltre ai revisori del codice un motivo per dire a uno sviluppatore perché deve essere ripetuto senza dire "Non mi piace come l'hai fatto", che a nessuno piace sentire o dire.

Le recensioni sui codici dovrebbero avere un impatto . Dopo una revisione del codice, i risultati dovrebbero essere attuati piuttosto presto. Non ha senso fare la recensione se non cambia nulla comunque. Allo stesso modo, lo sviluppatore che ha creato il codice ha bisogno di per sapere perché il codice ha dovuto cambiare, o potrebbe continuare a fare la stessa cosa in futuro e il revisore del codice si stancherà di correggere ripetutamente la stessa cosa .

Keep it fair . Come qualsiasi attività indesiderabile, la stessa persona non vorrà eseguire la revisione del codice tutto il tempo. Se qualcuno rimane bloccato a farlo la maggior parte del tempo, tutti gli altri cercheranno di spingerlo su quella persona, attivamente o semplicemente non volontariamente. Avrai bisogno di impostare "turni", o se hai solo poche persone di cui ti fidi a fare la recensione, chiedi a tutti di leggere il codice contemporaneamente. Ciò stabilirà quali sono gli standard di codifica e gli sviluppatori più recenti saranno a proprio agio nel fare le revisioni del codice.

In conclusione, la revisione del codice spesso sembra un dolore per tutti i soggetti coinvolti. Non dovrebbe essere un compito assegnato a una singola persona / coppia di persone. Solo condividendo il dolore, agendo sul risultato, e facendo in modo che i nuovi sviluppatori imparino dai loro errori, tutti possono venire avanti.

Lavoravo in una casa editrice piuttosto che in una compagnia di software, ma il principio è lo stesso.

Nella casa editrice, la strada per la gestione (e posti di lavoro più remunerativi) era la modifica / revisione del lavoro di altri professionisti, più giovani. Alcune persone si accontentavano di rimanere scrittori senior, senza responsabilità di revisione / revisione, ma "la maggior parte" (più della metà) delle persone competenti desiderava questi lavori di revisione / revisione. NON avere uno di quei lavori era una sorta di stigmatizzazione, perché era una "limitazione della carriera", quindi la maggior parte dei "giovani" ha cercato di passare al montaggio il più presto possibile.

Per prima cosa rispondi alla domanda perché vuoi che gli sviluppatori facciano revisioni del codice. Ci sono troppi bug, le convenzioni di codifica non sono seguite, la conoscenza non è condivisa, il codice è stato controllato con test insufficienti, ecc.

Quindi discuterne con gli sviluppatori. Dì loro cosa ti aspetti e chiedi loro come migliorerebbero in questo. Dovrebbero tutti essere d'accordo nell'attuare questi cambiamenti o sarà difficile farli rispettare.

Se tutti sono d'accordo che la revisione del codice sia utile, quali sono normalmente, allora una nuova regola potrebbe essere che d'ora in poi solo il codice recensito può essere inserito nel prodotto.

Per essere in grado di fare una revisione dovrebbe essere chiaro cosa ci si aspetta. Definisci quindi quali regole si applicano al codice, ad esempio:

• convenzioni di codifica (denominazione, stile del codice)
• soluzioni predefinite
Costrutti
• per evitare

Utilizza buoni strumenti, quindi trova facilmente il codice da esaminare, visualizza le modifiche e parla di tali modifiche.

La revisione del codice dovrebbe diventare parte del normale flusso di lavoro per implementare una modifica. Questo potrebbe essere organizzato in questo modo:

• uno sviluppatore dovrebbe trovare qualcun altro per fare una revisione delle modifiche da includere.
• oppure, per ogni modifica confermata, devi eseguire una revisione.

Lavoro per un grande rivenditore di scatole. Dove le vecchie abitudini sono dure a morire. Mi piace, davvero difficile. Quindi ho pensato di condividere le mie esperienze.

Il problema che abbiamo avuto è la visibilità. Nessun codice era realmente visibile l'uno all'altra. Stavano usando CVS e abbiamo vinto la vittoria convertendo tutto per usare git. Questo ha iniziato a cambiare la situazione. Abbiamo implementato Gitlab (simile a github, praticamente tutte le stesse funzionalità ospitate sui tuoi server). Abbiamo protetto il ramo principale (codice di produzione pronto). Questo ha creato un effetto a palla di neve di sorta. Se uno sviluppatore aveva qualcosa che doveva essere unito alla produzione o ad un ramo dell'ambiente di test, avrebbe bisogno di 2 sviluppatori senior per esaminare il codice, fare commenti, suggerimenti per miglioramenti, porre domande ecc. E infine dare un pollice in più sull'unione richiesta. Da lì, verrebbe unito all'ambiente.

Entrare per riscrivere semplicemente il codice che non ti piace non ti aiuterà né ai tuoi sviluppatori. È la definizione di follia.

Ecco un riepilogo dei modi in cui ci assicuriamo che produciamo codice di qualità.

1. Test di unità - Suddividi i requisiti in piccole domande logiche di dimensioni minuscole e scrivi test su ciò che il chunk dell'applicazione dovrebbe fare, aspetta e ritorna.
2. Scrivi documentazione - Fai finta di essere una nuova assunzione e ti viene chiesto come fare X. Se il tuo codice non ha documentazione, in pratica qualsiasi sviluppatore che si avvicina al codice è come "Whoah ..." e di solito prende un bel po 'di tempo di accelerazione solo per capire cosa sta succedendo sotto il cofano. Semplicemente non credo nella mentalità "Il buon codice si documenta da solo".
3. Empower Developers - Non prendere la tastiera. Fai domande che stimolano il pensiero nel tentativo di portare avanti le decisioni guidate dal pensiero.
4. Scrivi più documentazione - Non posso sottolineare abbastanza la buona documentazione. È letteralmente inestimabile per un'organizzazione perché le persone cambiano lavoro, se ne vanno o vengono licenziate ea volte tutte le informazioni su un modulo vanno con loro.
5. Uso del controllo della versione (Git + Gitlab) - Questo è un grande aiuto. Se sei in grado di implementare qualcosa di simile ti consiglio caldamente di farlo. Questo avrà molti più occhi sul codice base, unire richieste, produttività ecc. Dal tuo team. È fantastico.
6. Guida allo stile di codifica : crea una guida di stile che vorresti vedere seguita quando altri stanno codificando. Alla fine della giornata, tutto il tuo codice dovrebbe apparire come se fosse stato scritto da una sola persona. Non 100.
7. Divertiti - Cosa? Eh? Coding divertente? Se riesci a renderlo più simile a un gioco (pensa ai risultati di xbox), le persone tendono a provare un po 'di più e sembra molto meno lavoro. Usiamo un server di build Jenkins che compila parte del nostro codice lato client. Durante questo processo abbiamo usato CSS Lint e JS Lint per trovare problemi e cattive abitudini nel nostro codebase e documentarli. Se tu fossi quello che ha fatto errori nel codice, ti sei fatto male. Se hai pulito il codice e ridotto i problemi, hai punti. Abbiamo notato immediatamente che gli sviluppatori stavano setacciando la base di codici in cerca di problemi che li avrebbero guadagnati punti. ( Il plug-in per il gioco di integrazione continua )

Spero che questo aggiunga un po 'di valore alla tua situazione e questo post ti aiuta in qualche modo. Così tante grandi risposte qui.

Forse un modo per aggirare la riluttanza chiara della tua base di sviluppatori esistente per esaminare il codice sarebbe di introdurre una posizione di "tutoring / reviewing" che operi separatamente.

In questo modo l'individuo assunto per la posizione di tutoraggio avrebbe suscitato interesse da parte di individui che cercavano di migliorare le proprie abilità, pur avendo anche un ruolo ben definito di revisione del lavoro degli sviluppatori junior.

Ciò lascerebbe i tuoi sviluppatori senior liberi di concentrarsi sui loro punti di forza, in via di sviluppo.