Come si fa a far accettare la revisione del codice? [duplicare]

Ho scoperto che le persone a cui non piacciono le recensioni del codice fanno del loro meglio per aggirare qualsiasi cosa tu abbia messo in atto.

Il modo migliore per assicurarti che il codice con cui lavori sia correttamente revisionato dal codice è di lavorare da qualche parte che lo consideri come il normale modo di codificare e che ingaggia solo sviluppatori che probabilmente si adattano bene a quell'ambiente.

Se non riesci a cambiare con chi lavori, potrebbe avere successo se prima dai il tuo codice per la revisione. Incoraggiarli a trovarlo in errore (oserei suggerire di aggiungere qualche errore intenzionale?) In modo che tu possa dimostrare che è non che vuole essere un modo di criticare lo sviluppatore in questione. Questo è il problema principale, IMO: le persone prendono personalmente le recensioni del codice.

Semplice: assegna i progetti importanti ai programmatori che accettano le revisioni del codice. Questo è un chiaro messaggio: questo progetto è troppo importante per andare ai dilettanti.

I programmatori che non collaboreranno possono fare lavori di manutenzione. La tua azienda ne avrà in abbondanza, se le revisioni del codice non venissero fatte ampiamente. Metti in chiaro che questa è una strada senza uscita. Questi prodotti diminuiranno di importanza, verranno eliminati o sostituiti da prodotti più recenti sottoposti a revisione del codice.

Metti in chiaro quando assumi che le revisioni del codice sono la norma nella tua azienda. Assegna i nuovi assunti che accettano le revisioni del codice ai nuovi progetti.

Nel complesso, questo dirà ai tuoi sviluppatori che la società sta adottando le revisioni del codice. Possono scegliere: andare avanti o uscire. Non c'è futuro in nessuna azienda per le persone che combattono contro la compagnia.

Beh, non puoi davvero, se qualcuno rifiuta categoricamente e tu non sei il loro capo.

Ma la ragione principale per adottare un altro stile è ...

Coerenza

Penso che qualunque stile pazzo ci sia, deve essere coerente. Quindi, se un progetto è costruito in questo stile, in genere deve rimanere in questo stile, a meno che non vi sia un motivo eccezionalmente valido per cambiare. Quindi se il loro stile non corrisponde; è un fatto che dovrebbe essere fatto per abbinare. Nessuna domanda qui.

Ci sono altri problemi che si possono notare che sono semplicemente sbagliati. Sicurezza, 'torto' generale, ecc. Questi sono indiscutibili e dovrebbero essere cambiati.

Se qualcuno si rifiuta di riconoscere qualcosa come un cattivo design, dopo aver mostrato loro il modo corretto e mostrato tutti i rischi e i problemi con quello che fanno, penso che tu debba decidere da solo come agire. Ma speri che non lavori con persone che sono così irragionevoli.

Sono programmatore e mi piacciono le recensioni del codice. La chiave per una buona revisione del codice nella mia esperienza sta rendendo il codice migliore.

Quando eseguo una revisione del codice con un collega e lui / lei indica potenziali miglioramenti o bug in agguato, sono felice. Il codice migliora e probabilmente diventeremo entrambi un po 'più intelligenti. Perché non mi piacerebbe?

Sfortunatamente alcune persone vedono le revisioni del codice come un modo per sottolineare il fatto che il codice deve avere 4 indentazioni spaziali invece di 3 rientri spaziali o qualche altro dettaglio non vitale.

Assicurati che le persone che eseguono la revisione del codice possano e forniranno informazioni utili. Se le sole recensioni del codice di input fornite sono qualcosa che può essere facilmente realizzato utilizzando uno strumento, le revisioni del codice sono una perdita di tempo.

Assicurati che le recensioni del codice non siano una perdita di tempo e che la maggior parte degli sviluppatori le apprezzerà.

Quando gestisco un progetto, se dico che faremo delle revisioni del codice, faremo delle revisioni del codice. Fornirò ovviamente delle buone ragioni per farli, ma alla fine della giornata è mia responsabilità e decisione implementarli.

E se ai programmatori non piace, possono trovare un impiego alternativo. La maggior parte dei progetti falliti può essere migliorata in ogni modo eliminando metà degli sviluppatori e, secondo la mia esperienza, sono gli sviluppatori più poveri che si oppongono maggiormente alle recensioni di codice.

L'unica ragione per cui ho acquistato il codice durante la revisione del codice è che un anno fa la persona che ha provato a imporli ha tirato fuori la carta di superiorità e ci ha fatto rivedere il codice dell'altro per un determinato progetto. Alla fine di questo progetto ho potuto constatare l'enorme beneficio e ora provo a installare recensioni di codice sui miei progetti.

"Funziona" non è abbastanza. Il codice non è solo scritto per le macchine da eseguire, ma anche per le persone da leggere, adattare e migliorare. Se le persone non riescono a trovare la via attraverso il codice, non possono svolgere tutte queste attività che sono una parte importante della programmazione.

Se Joe Programmer dice: "Non guardare il mio codice, sono l'unica persona che ha bisogno di capirlo" Ne dubito. Solo in rari casi il codice viene toccato da una sola persona. E anche se questo è il caso: Joe capisce il suo codice la prossima settimana, il prossimo mese, dopo? Probabilmente no.

In quasi tutti gli ambienti commerciali (e la maggior parte non commerciali, vieni a quello) i programmatori non possiedono il codice che scrivono, il loro datore di lavoro lo fa.

In quasi tutti gli ambienti commerciali (e la maggior parte non commerciali, vieni a quello) la maggior parte dei programmatori sembra pensare che fa possedere il codice che scrive.

Questo causa un sacco di problemi con l'accettazione della revisione del codice come una tecnica di miglioramento del design ...

I modi per ridurre la resistenza potrebbero includere:

• introduzione programmazione coppie : nessun codice viene scritto a meno che due programmatori non lo guardino. Revisione immediata del codice in tempo reale. Assicurati che le coppie passino regolarmente.
• trova un modo per "anonimizzare" le revisioni del codice, in modo che non possa essere personale
• esaminare in piccoli blocchi, in modo che nessuno si trovi di fronte a lunghi elenchi di miglioramenti
• non consentire il check-in di alcun codice fino a quando non è stato revisionato (e i punti azione implementati e revisionati)
• introdurre un componente discrezionale da pagare, a seconda dell'accettazione delle recensioni del codice

Non raccomando alcuno (beh, forse il primo) in particolare.

Ciò che conta è avere una vera comprensione di ciò che le obiezioni reali alle recensioni sono, non di ciò che stai ascoltando in superficie. Forse applicare 5 Whys per approfondire?

Non mi piace la revisione del codice quando sono uno sviluppatore.

Ma voglio davvero una recensione del codice se sono un leader. Sappiamo perché.

Tuttavia, alcuni sviluppatori saranno sicuri di non gradire la revisione del codice, proprio come me.

Che ne dici della recensione del codice anonimo ?

Possiamo scrivere esempi di pezzi di codice o suggerimenti dopo la revisione del codice per capire quale sia il modo migliore.

Un semplice esempio:

pezzo originale :

s=objGotFromSomewhere.doSomething()

pezzo migliore :

if(objGotFromSomewhere!=null){
      s=objGotFromSomewhere.doSomething()
  }

nota :

In alcuni progetti, abbiamo ottenuto ... problema, causato da .. motivo

suggerimenti :

controlla sempre ...

Possiamo mettere questo in wiki o da qualche parte, quindi parlarne nella riunione settimanale del team. Tech Leader lo farà, e incoraggerà gli sviluppatori senior e ogni membro del team a farlo anche.

Penso che anonimo sia importante, il che significa che nessuno sa chi ha generato il codice errato.

Le persone potrebbero non gradire la revisione del codice, ma vorranno sapere qual è il modo migliore .

Ho fatto delle buone esperienze con le recensioni di coppia. Due persone stanno esaminando il codice sorgente l'uno dell'altro mentre entrambi sono seduti davanti allo stesso monitor. Facciamo in modo che non siano sempre le stesse persone e che sia chiaro e concordato in anticipo ciò che entrambi stanno cercando.

Ma fare ancora recensioni di codice richiede persone con una mentalità aperta che sono disposte ad accettare critiche.

Avere un'autorità superiore dovrebbe far funzionare un processo di revisione. Persino coloro che si ribellano contro l'idea in un primo momento dovrebbero sperare di vederne i benefici. Se non lo fanno ... beh, non può davvero aiutarlo.

Se sei solo un combattente solitario tra coetanei disinteressati avrai un tempo molto più difficile. La chiave di entrambi gli scenari è di far capire ai recensori che non è un attacco personale alle loro abilità, ma piuttosto uno sforzo di squadra per schiacciare i bug everyones in modo più efficiente.

Il modo migliore è che la decisione venga dai programmatori che la producono.

Suggerirei di usare alcune abilità della gente e iniziare con una discussione su come assicurarsi che il gruppo possa lavorare insieme, vorrei anche parlare dei modi per assicurarmi che le abilità sul posto di lavoro dei programmatori siano aggiornate.

Il modo migliore per fare revisioni del codice è ovviamente, ma ci sono anche altre strade che potrebbero avere successo, ad esempio leggere e discutere un libro su come programmare. Raccomando "Codice pulito: un manuale di abilità software agile" ( link ).

Un'altra cosa è lasciare che ogni programmatore presenti i suoi progetti davanti al gruppo quando hanno finito di fare qualcosa. Questo naturalmente farà in modo che le cose più brutte non vengano scritte, e tutti si sentiranno orgogliosi di aver realizzato qualcosa.

Come fai a rendere le persone accettate la revisione del tuo codice?

Non puoi, quindi non lo fai. E tu non sei responsabile per il lavoro di qualcun altro finché non ti viene chiesto di assumersene la responsabilità.

Potresti accedere alla tua "recensione", quindi è più come "feedback". Non sei il capo alla ricerca di cose che qualcun altro ha fatto male, sono due professionisti che discutono approcci diversi allo stesso problema.

IMO, ogni due programmatori troverà diversi modi per risolvere un problema e entrambi possono avere ragione.

Chiedi al recensore, 'Cosa vedi come il vantaggio di adottare questo approccio?' Fornisci anche gli svantaggi che vedi e i vantaggi del tuo approccio alternativo. Chiedi il riconoscimento dei DA che hai indicato- "sei d'accordo che questo potrebbe essere un problema con il codice che hai?"

Penso che la maggior parte dei conflitti di programmazione provengano da differenze di valore e indovino cosa potrebbe accadere in futuro. Le persone possono passare ore a discutere su qualcosa di completamente indeterminato. Concentrati su problemi reali ora, meno su (ma non evitando) cose che potrebbero accadere più tardi.

Utilizziamo ReviewBoard per fare recensioni. Nella nostra azienda, le recensioni sono volontarie: se stai facendo qualcosa di interessante (sostanziali aggiunte o modifiche) ti aspettiamo che tu crei una recensione-richiesta che deve essere fatta dai colleghi della tua squadra. I membri del team selezionati possono quindi approvare la revisione o richiedere ulteriori modifiche.

Se hai la necessità di forzare le revisioni perché un programmatore non sta giocando, potrebbe essere necessario che tutti i commit sullo SCM vengano forniti con un ID di revisione che viene contrassegnato come approvato prima di essere accettato.

Se sei il responsabile del progetto dall'inizio o lo sviluppatore principale, dovresti essere in grado di condurre revisioni di codice istituendole come parte della tua metodologia di progetto. Assicurati che le recensioni vengano eseguite conducendole da soli, se necessario. Se sei al comando e alcune persone non seguiranno il tuo esempio, allora devi persuaderli a prendere il programma o sostituirli con persone che lo faranno.

Se non sei responsabile, devi convincere i membri del team che è un vantaggio per loro eseguire revisioni del codice. Inizia convincendo gli altri membri del team a rivedere il tuo codice. Documenta il tuo design e le interfacce e guidali attraverso il tuo codice. Quindi scrivi un sommario di revisione post e gli elementi di azione per te stesso e distribuiscilo ai membri del tuo team. Se c'è un vantaggio da questo, diventerà presto evidente alla squadra.

Se c'è resistenza, devi scoprire quali sono le obiezioni delle persone. Potrebbero essere validi. Ad esempio, il progetto potrebbe essere abbastanza piccolo e l'intero team potrebbe essere abbastanza esperto da consentire a tutti gli utenti del progetto di revisionare in modo efficace tutto il codice nel progetto, anche senza revisioni formali.

Trovo le revisioni del codice più utili su progetti di grandi dimensioni in cui non è possibile che una sola persona batta tutto il codice, dove ci sono sviluppatori inesperti che hanno bisogno del feedback per sviluppare le loro capacità di codifica e analisi o dove ci sono membri non codificanti del team che devono comprendere il design e il codice. Trovo le recensioni essenziali o addirittura obbligatorie in caso di conseguenze legali o peggio se il codice non riesce (ad esempio i sistemi di controllo del volo dell'aeromobile). Li trovo ridondanti quando lavoro con programmatori esperti, in cui tutti i membri del team producono codice, in cui il progetto è di piccole dimensioni ei membri del team leggono e criticano il codice in ogni momento.

Non pensare sempre che il problema sia alla loro fine. Forse lo stai facendo male.

Scopri perché a loro non piace e invece di assumere automaticamente che siano un "programmatore cattivo", considera prima di tutto se possono avere un punto e che potresti essere un cattivo recensore del codice o semplicemente comunicare male. È possibile.

Se le tue regole di revisione / stile del codice non sono soggettive, arbitrarie o folle, allora sarà facile spiegare la motivazione per loro a qualsiasi programmatore competente e professionale. Se non puoi, allora forse hai bisogno di ripensare a quello che stai facendo o come lo stai presentando.

Altrimenti, se il problema riguarda solo uno o due individui, è probabile che si tratti più di un problema delle risorse umane più profondo con quelle persone e nulla a che fare con la revisione del codice in modo specifico, la revisione del codice è solo un sintomo di quel problema più grande.

Il principio 1-3-2 si applica qui (parlo prima persona, poi terza persona, poi seconda - in questo ordine).

La prima priorità è quella di esercitarsi su ciò che predico , il che significa che prima sono interessato a dire che "I" ha bisogno di revisioni del codice (e della loro esecuzione).

Quindi, solo se l'atmosfera non si auto-adatta alle recensioni del codice, comincio a dire che "le persone" hanno bisogno di recensioni del codice (ed elenca le buone ragioni).

Solo dopo, se tutto il resto fallisce (e io sono in autorità :)), stabilisco la legge e dico "tu" hai bisogno di recensioni del codice. Questa è la parte su cui le persone hanno correttamente enumerato, ma io sussulto solo quando la mentalità della terza persona non è l'ultima. Se non riesco a parlare con il primo pugno della persona e non pratico quello che predico, non sono solo un persuasivo "inefficace", ma sono solo più un idiota.

ps. Notate come ho detto tutto questo in prima persona:)

Per offrire un'altra prospettiva, a volte ho scoperto che le revisioni del codice vanno alla deriva in cose che non hanno senso nemmeno discutere. Come se avessi fatto leggere a questo ragazzo il mio codice dicendo che non ho la punteggiatura corretta (una battuta) in uno dei commenti che ho aggiunto al codice. Mentre è soggettivo se una cosa del genere sia importante (se stai scrivendo la documentazione inline che verrà inserita nei documenti rilasciati, ad esempio, potrebbe essere importante), nel mio caso non era chiaramente.

Penso che le recensioni di codice siano obbligatorie, sono stato quasi sempre aiutato dai commenti sulla revisione del codice, ea volte ci vuole un po 'di tempo perché un nuovo membro del team capisca perché sono importanti. Ma è anche importante mantenere l'obiettività, ogni suggerimento dovrebbe avere una ragione obiettiva e non dovrebbe essere fatto a causa delle preferenze soggettive di un revisore.

Quindi, per rispondere alla domanda, è opportuno guidare i nuovi membri del team sull'importanza e lo scopo della revisione del codice, in una fase in cui è probabile che ascolteranno. E con l'esperienza, impareranno che non è personale. Inoltre, è importante che le persone giuste siano revisori, non persone che impongono le proprie opinioni soggettive sugli altri.

Penso che il maggior problema con le revisioni del codice sia che alcune persone non riescono a farle correttamente. Ad esempio mettere la finale di fronte alla classe / metodo / parametro / qualsiasi cosa non ha importanza e non dovrebbe essere in una revisione del codice. Un altro esempio è l'utilizzo del ciclo errato poiché solo foreach è ok. Richiede di commentare tutto. Ottimizzazioni String + / StringBuilder / StringBuffer. Se avessi una recensione del codice con una di quelle cose, penserei che quel tipo sia un idiota e se non fossi obbligato a cambiare il codice non lo farei.

Anche a volte gli strumenti di revisione del codice sono semplicemente sbagliati, ad esempio i PMD (Java) di default per dire che la classe ha troppi metodi, quindi quello che ho fatto è creare una classe genitore astratta e spingere alcuni metodi lì. Avrei potuto dividere la classe in 2 classi, ma penso che l'API sarà più facile da usare con tutti quei metodi in una classe (è una piccola lib e la mia decisione progettuale). Alcune persone usano sempre solo il valore predefinito, quindi non dovrebbe essere schifoso.

Devi accettare che non puoi "far sì che le persone accettino la revisione del codice.

Puoi fare in modo che un compilatore faccia ciò che vuoi, ma con gli umani, il meglio che puoi cercare è:

"How can I be more influential when reviewing another person's code?"

... e questa è un'altra domanda completamente.

Esamina le domande, non i comandi

Penso che un problema fondamentale con il tuo processo di revisione sia la tua idea di dover forzare qualsiasi cosa in gola. Invece, fai domande come "Perché hai deciso di seguire X approccio invece di Y?"

Questo farà riflettere sul proprio processo di codifica, invece di costringerli ad accettare il processo di codifica. E hey, potresti anche imparare qualcosa.

Per prima cosa, come per tutti i problemi, inizia a risolvere da solo questo. Assicurati di fare tutto per rendere le revisioni del codice più produttive e non conflittuali possibili.

1. Non utilizzare le revisioni del codice per applicare le best practice quando è possibile utilizzare l'automazione di qualche tipo. Avere a portata di mano le librerie standard per eseguire le attività più comuni: crittografia, accesso ai database, ecc. Utilizzare AOP e policy injection per gestire standardizzati di registrazione, auditing, vincoli di sicurezza, ecc. Invece di affrontare gli sviluppatori e indurli a farlo nel modo giusto "modo, rendi più facile farlo. Siamo pigri, quindi seguiremo il percorso di minor resistenza.
2. Non riesaminare nomi di variabili, blocchi di commenti standardizzati e altri dettagli nitpicky. A meno che il nome della variabile sia difficile da capire, va bene. "Consistenza" è solo una scusa per esercitare l'autorità e tutti possono vederla attraverso.
3. Non fare le recensioni con il ragazzo più grouchiest del tuo gruppo. Oppure, fai attenzione a non avere persone con conflitti di personalità che riesaminano il codice dell'altro.
4. Avere snack e bevande ad ogni revisione del codice. A tutti piacciono gli spuntini e le bevande.

Non ho mai avuto la possibilità di essere coinvolto nella revisione del codice, ma penso che sia sicuramente una pratica eccellente.
Affinché la revisione del codice sia ben accettata, potresti avere qualche formazione organizzata su come fare "critiche positive".

E, a proposito, una tale formazione potrebbe anche essere un'opportunità per ricordare alle persone i principi di sviluppo dell'azienda / del progetto e fare un po 'di team building.

Le revisioni del codice sono una parte essenziale della prevenzione di un grave disastro nelle fasi iniziali. Molti dei principali negozi di sviluppo richiedono la revisione dei codici sui loro progetti.

Per facilitare l'accettazione delle persone, dovrebbero esserci delle linee guida che il revisore deve seguire. Se l'individuo si sente come se fosse stato individuato o che il revisore potrebbe avere rancore, potrebbe essere riluttante a passare attraverso una recensione. Se in anticipo tutti saranno informati delle linee guida e di ciò che il revisore cercherà, potresti ricevere una migliore ricezione. A nessuno piace la soggettività quando riflette sulla loro carriera o performance.

Parlando dall'esperienza, ho lavorato con un certo numero di sviluppatori su contratti governativi di alto profilo che erano la revisione anti-codice. Dove ci ha portato? Molto indietro rispetto al programma e molto oltre il budget. Gli sviluppatori con qualcosa da nascondere saranno resistenti alle persone che stanno attraversando il loro lavoro poiché sono ben consapevoli delle loro carenze.

È stata la mia esperienza che coloro che non sono disposti o sono resistenti alle recensioni sono anche le stesse persone che non sono disposte a imparare e ad adattare il loro modo di pensare al problema che può essere una pista scivolosa per un progetto quando la persona è in un ruolo decisionale.

Qualcos'altro a cui pensare; se il budget e l'azienda possono renderli disponibili, chi ha il compito di eseguire esclusivamente revisioni di codice o addirittura portare qualcuno da un altro progetto a fare la revisione. Se non esiste una relazione precedente, potrebbe essere più semplice per entrambe le parti.

Se tutto il resto fallisce e sei preoccupato, l'atteggiamento delle persone potrebbe creare problemi per il progetto nel suo insieme, documentarlo e inoltrare la questione a un superiore in modo rispettoso. Andare dietro a qualcuno o far notare i loro cortometraggi ti farà male e potrebbe attirare l'attenzione sul tuo lavoro.

Un'altra opzione: trattiamo periodicamente "riflessioni" sul nostro processo con tutti i programmatori di un progetto. Parte di questa pratica consiste nel fare una "analisi delle cause principali" sui bug che sono emersi di recente. Cosa ha causato questo? Era una regressione? Era una mancanza di test IE6? Chiedere a Joe di questo ha aiutato? L'obiettivo è capire perché stiamo avendo questi bug e cosa possiamo cambiare per prevenirli.

Se le revisioni del codice sono uno strumento appropriato, questo verrà fuori durante la discussione. E saranno i programmatori stessi che lo introdurranno, e così riceverai molto più buy-in fin dall'inizio. Abbiamo concordato che tutto il codice deve essere rivisto prima di essere archiviato. Generalmente gli sviluppatori lo chiedono, ma se lo dimenticano, lo ammettono confusamente ... sanno che non stanno solo sfidando la "gestione", ma andando contro l'accordo della squadra .

(O se non è uno strumento appropriato, le persone hanno la possibilità di spiegare perché).

Nella mia esperienza, la coppia programmazione ha molti più vantaggi delle semplici recensioni. Non solo trova più bug, ma incoraggia soluzioni più creative, condivisione delle conoscenze, team building, comunicazione aperta e consente a un team di perfezionare continuamente uno stile di programmazione naturale.

Ogni volta, sono stato in un team che ha provato le recensioni, diventa conflittuale e poi svanisce quando incombe un termine difficile.

Può essere difficile per uno sviluppatore esperto adeguarsi all'idea delle recensioni, ma quando fa clic lo slancio riprende davvero. Provalo per un paio di settimane e vedi se funziona per te.

Ho una situazione diversa. Dato che non sono uno sviluppatore molto esperto, vorrei fare una revisione del codice per il mio codice prima di ogni uscita. Ma la maggior parte delle volte, la revisione del codice non rientra nei nostri tempi ristretti. Oppure, la mia azienda non pensa che sia abbastanza importante da giustificare il caso. Lo stesso per lo sviluppo basato sui test. Se ho davvero delle domande, afferro uno sviluppatore senior per vedere il mio codice. Non ideale, ma farlo mi aiuta a migliorare le mie capacità di codifica.

Se non faranno le revisioni del codice, allora semplici ... mettili via. Chiaramente non sono troppo interessati a migliorare comunque. Non c'è bisogno di mantenere il peso morto intorno.