Ho notato nel tuo post cose che potrebbero essere collegate a quella situazione:

• Sei il miglior revisore del tuo team
• Sei anche uno dei più anziani membro
• La tua produttività individuale è monitorata in base al codice prodotto

Pertanto

• Il tuo team potrebbe dimenticarsi che devono fare codice recensioni dato che ne fai così tante
• Il tuo team potrebbe pensare di non avere le capacità necessarie per "giudicarti"
• Il tuo team potrebbe pensare di dover concentrarsi o dare priorità la loro produzione di codice invece.

Non dovresti aver paura di chiedere la revisione ai tuoi colleghi e per una potenziale ragione non rivedono il tuo codice. Il mio approccio sarebbe quello di avere una conversazione con i colleghi in un piccolo comitato o 1 contro 1, perché penso che sarebbe più facile essere onesti lì, ma potresti anche iniziare a chiedere durante le riunioni, ad es. retrospettive e simili. Dato che disponi di metriche, potresti chiedere alle persone che fanno meno recensioni ed essere rassicurante sul fatto che è sia facile che apprezzato.

Alla fine, dopo aver chiesto più volte alle persone, prenderanno le buone abitudini di dare un'occhiata alle recensioni e rivedere le cose da sole. Spesso eseguiamo il ping di noi stessi in chat per le revisioni in sospeso e il carico è abbastanza equilibrato ora.

Penso che il problema qui sia che ci si aspetta che i membri del team forniscano il proprio lavoro, invece di avere un obiettivo comune di consegna.

Se ogni ingegnere ha il proprio codice da scrivere e consegnare e si misura sul raggiungimento di questo obiettivo (e non sul raggiungimento di un obiettivo di squadra), quindi ovviamente non vi è alcun incentivo a rivedere le modifiche al codice di altre persone.

Non sono sicuro di cosa puoi fare come singola persona fare per cambiarlo, però - questo deve essere affrontato da un punto organizzativo (cioè il tuo manager, o un proprietario del prodotto o simile). Il team deve avere chiare priorità su ciò che è più importante, e poi quei bit di consegna dovranno essere rivisto prima di lavorare su altro codice.

Vai alla scrivania dei tuoi colleghi e chiedi loro se sono disponibili per una revisione del codice. Per quelli brevi molto probabilmente saranno d'accordo, per quelli più lunghi potrebbero chiedere di farlo in un secondo momento, cogli l'occasione per specificare una fascia oraria per la tua revisione.

Se davvero ne hai bisogno puoi impostare formalmente un può essere utile sia per garantire che la revisione del codice abbia luogo sia per impedire a te o al tuo revisore di essere disturbati da altre persone.

In primo luogo, non interiorizzare la mancanza di revisione del codice come un problema che il tuo team ha con te. Sembra che tu stia pensando che la mancanza di revisione del codice sia una colpa personale nei tuoi confronti, il che probabilmente non è il caso. A volte le persone sono impegnate o non vedono il vantaggio di rivedere il codice. Non è un attacco.

In secondo luogo, se vedi la necessità di revisioni del codice e il team non sta impegnando il tempo, parla con il tuo manager. Alcuni posti in cui ho lavorato avevano un tempo prestabilito ogni settimana per le revisioni del codice e avremmo eliminato alcune delle revisioni più critiche come team per modifiche con priorità maggiore o maggiore. Quelli più piccoli potremmo rivedere in coppia come consentito dai nostri programmi. Ma non abbiamo mai permesso che il codice venisse unito senza una revisione.

Parla con il tuo manager della definizione di una cadenza di revisione del codice che funzioni per il tuo team e sii aperto che il tuo manager potrebbe non vederlo come una modifica importante per strumento. Per alcuni manager, le revisioni del codice non sono importanti fino a quando non vedono come può migliorare i profitti.

Non sei tu, il problema è la cultura del team. Aggirando le revisioni del codice, il team non segue le pratiche di ingegneria del software e non capisce perché sono importanti. Questo è un problema critico che necessita di una modifica al più presto. Questi punti devono essere affrontati:

• Perché è importante.
• Per chi? e chi dovrebbe farlo? Vorrei chiarire che la revisione del codice non dovrebbe essere effettuata solo dagli anziani e che anche gli anziani hanno bisogno che il loro codice venga rivisto. Ho visto team che hanno introdotto regole di applicazione di git come il ramo protetto che necessita di due revisori.
• Come eseguire la revisione del codice e come fornire un feedback appropriato.

Le aspettative dovrebbero essere chiaro. Questi punti devono essere presentati al team (es. Riunione, pranzo & impara). Il cambiamento è difficile, preparati e cerca alleati.

Ciò che ha funzionato per me è stato assegnare esplicitamente qualcuno per la revisione. Nel nostro progetto attuale, arriviamo persino a riassegnare il problema in JIRA al revisore. Se non puoi assegnarlo a un'altra persona, assegnalo a chi può (il project manager). Non importa che la persona faccia effettivamente la revisione, è importante che la persona si prenda cura di una revisione.

Assegnare una persona specifica significa che questo è ora, in modo tracciabile, un todo di quella persona. Trovo che anche per me, che fa la maggior parte delle revisioni, sia utile se mi vengono assegnate attività di revisione: rende chiaro che un'attività è in uno stato per la revisione e che il progresso è bloccato da me in questo momento / che lo sono responsabile in questo momento.

Mi trovavo in una situazione molto simile. Ragazzo di qualità, manager che si complimentano, si prendono cura meticolosamente delle consegne, buoni rapporti con le persone al di fuori del lavoro.

Era in cima alla mia lista di priorità essere un grande artista. Un giorno un nuovo ragazzo nella mia squadra mi ha detto di aver sentito che sono uno stronzo ma tutti mi amano. Feedback onesto a 360 gradi. :)

Quello che ho capito allora è stato che ero così ossessionato dalla perfezione che le persone erano la mia seconda priorità. Ancora una priorità assoluta, ho fatto tutto il possibile per le persone, tranne sacrificare la qualità.

Le persone lo sentono. Anche se non è cosciente da parte mia, ho camminato in alto come se la qualità fosse il mio secondo nome. Mi sono reso conto che questo fa sentire le persone secondarie o inferiori.

Metto le persone come prima priorità per davvero immediatamente, perché quella era comunque la mia intenzione, semplicemente non vedevo che non ci sono .La vita è migliorata molto, le persone hanno sviluppato così tante nuove competenze, il team è diventato fantastico, la qualità era forte e costante.

Questo potrebbe non essere applicabile alla tua situazione, lo lascio qui, forse aiuta.

Consenso

Non puoi convincere i membri del team a rivedere il tuo codice se il tuo team non è d'accordo sul fatto che le revisioni del codice siano preziose. Direi che la revisione del codice è una delle tre cose di cui la maggior parte degli sviluppatori non fa abbastanza. Quindi il primo passo è parlare semplicemente della revisione del codice in una riunione con tutto il tuo team (compresi i manager). Chiedi loro cosa ne pensano, se è prezioso e quanto spesso dovrebbe essere fatto.

Scommetto che almeno la metà di loro pensa che sia una perdita di tempo. Se è così, il tuo primo passo è l'istruzione. È necessario estrarre recensioni in cui sono stati fatti commenti preziosi, specialmente se qualcuno ha rilevato un bug reale prima dell'unione (non dovresti vendere CR come strumento di ricerca di bug, ma è un bel bonus quando succede). Se i tuoi colleghi non hanno esperienza, potrebbe essere difficile vendere. Anche così, è qualcosa che dovresti sollevare delicatamente il più spesso possibile, in modo che alla fine assorbano l'idea che CR -> migliore qualità -> codice migliore -> meno bug -> migliore qualità della vita per gli sviluppatori.

Applicazione

Una volta che hai convinto il team a sostenere almeno a parole l'idea che la CR è preziosa, devi creare un meccanismo per applicarla. Idealmente, il tuo sistema di controllo della versione fa questo (banale da configurare su GitHub, per esempio). Se nessuno può unire senza ottenere una risposta predefinita, allora si spera che tutti abbiano un collo di bottiglia e siano quindi incentivati ​​a eliminare il backlog. Quando ciò accade, devi fare qualcosa che a prima vista può sembrare infinitamente difficile per te: non devi fare nulla. Esiste un numero medio di PR prodotte per sviluppatore e ogni sviluppatore deve quindi eseguire quel numero di CR per avere un'equa distribuzione del lavoro. Devi stimare quel numero e non fare più di altrettanti CR.

Presto tutti i membri del team si lamenteranno del fatto che c'è un enorme arretrato di PR in attesa di unirsi e devi chiarire che l'intero team deve sostenere il carico di esaminarli. Ricorda loro delicatamente che hanno concordato sul valore e resisti a qualsiasi chiamata per rimuovere il blocco CR sulle unioni. Molto probabilmente, faranno CR a malincuore e sporadicamente. Per aiutare ad assegnare la responsabilità, ho creato uno strumento per il mio team che ha eseguito un'assegnazione round robin molto semplice di PR agli sviluppatori. Tutti potevano vedere chi non stava facendo recensioni e tutti sapevano con chi parlare se il loro PR era bloccato durante la revisione. Il solo fatto di avere questa visibilità aiuta a far rispettare il comportamento desiderato.

Inoltre, l'anzianità ha davvero poco a che fare con questo fenomeno. Lo vedo in tutti gli sviluppatori di tutti i livelli. Molte volte sono gli sviluppatori junior cresciuti in una cultura del software più moderna ad abbracciare le revisioni del codice, mentre gli sviluppatori senior che sono abituati a fondersi senza revisione resistono. Quindi, in realtà, è solo una preferenza individuale che purtroppo è pervasiva in tutto il settore.

Aspettative

Infine, è necessario superare l'idea che i CR servono per trovare i difetti. La revisione del codice dovrebbe riguardare principalmente la distribuzione della conoscenza. Il solo fatto che qualcun altro legga la tua modifica rende un'altra persona del team consapevole del cambiamento e più probabilmente il team nota potenziali conflitti di progettazione con modifiche simultanee o imminenti. È anche per l'istruzione. Gli sviluppatori junior dovrebbero trarre vantaggio da eseguire una risposta predefinita quanto gli anziani, ma di natura diversa. Dovresti insegnare ai ragazzi che se non hanno critiche del codice che stanno rivedendo, dovrebbero porre domande . Sicuramente stanno imparando qualcosa di nuovo qua e là, o vedono qualcosa di inaspettato che è stato fatto in modo diverso da come lo farebbero loro. Porre queste domande e ottenere buone risposte li aiuta a capire quali pratiche sono specifiche per la tua azienda rispetto alle migliori pratiche generali di ingegneria del software.

Se qualcuno esprime riluttanza o esitazione a eseguire revisioni, in particolare del tuo codice, offriti semplicemente di associarlo alla revisione. Dì loro le cose che cerchi e chiedi loro di spiegarti il ​​tuo codice. Se nella loro spiegazione manca qualcosa di interessante, poni domande importanti per evidenziare il tuo punto. Se non riescono a capire un po 'a fondo, chiedi loro di porre una domanda sulla revisione per dimostrare che il tuo codice non era così auto-documentante come avrebbe potuto essere. Quindi passare attraverso uno dei loro PR o di qualcun altro e dimostrare gli stessi principi. Mostra con l'esempio che una risposta predefinita non deve essere intimidatoria e che può essere una preziosa esperienza di apprendimento per tutti.

Nei commenti hai menzionato che stai lavorando su cose più complicate rispetto al resto dei tuoi colleghi.

Questo sembra un doppio pericolo: il tuo codice non viene rivisto e altre persone non so come funziona l'argomento avanzato. Se vieni investito da un autobus, la squadra sarebbe nei guai.

Questo potrebbe anche essere l'angolo per affrontare il problema. Parla con il tuo supervisore su come pensi che questo stia rendendo vulnerabile il team e chiedi che 1-2 colleghi siano scelti per essere "iniziati" nelle cose difficili che stai facendo. Questo li rende la scelta logica per rivedere il tuo codice e migliora anche il tuo fattore bus.

Sembra un problema di processo e di gestione. In primo luogo, lavori in una squadra, quindi hai successo come squadra e fallisci come squadra. Se le consegne non vengono rispettate, è un fallimento del team. In passato, se avessimo avuto problemi con le revisioni del codice e i test tra pari, e come team abbiamo stipulato contratti per concordare che tutte le revisioni e i test tra pari dovevano essere eseguiti prima di iniziare una nuova attività di sviluppo e chiunque fosse sorpreso a infrangere le regole veniva chiamato su. Altre volte abbiamo semplicemente assegnato quelle attività in modo round robin. Tu, il tuo team e il tuo manager dovete risolvere questo problema insieme, ma non abbiate mai paura di segnalare un problema, soprattutto se le consegne non vengono soddisfatte. Sii sincero, diretto, ma educato. Inoltre, non aver paura di chiedere alle persone qual è il problema. Saresti sorpreso, la maggior parte delle volte te lo diranno solo.

Potrebbe non essere tu, o il processo, o il lavoro. Può semplicemente essere che a molti programmatori non piaccia fare ispezioni. Alcuni non credono in loro, alcuni non vogliono perdere tempo, altri sanno che non sono così bravi con loro.

Ci sono persone come te (e me) che sono molto disponibili a dedicare una discreta quantità di tempo per esaminare correttamente un cambiamento. Ci sono ragioni per cui lo facciamo. Non posso dire le tue ragioni, ma le mie includono cose come:
Ispeziono meglio della maggior parte dei designer con cui abbia mai lavorato,
Scrivo e leggo meglio della maggior parte, quindi anche i tuoi commenti verranno corretti,
Sono sulla difensiva riguardo al fatto che altre persone apportino brutti cambiamenti al sistema che potrebbero influenzare me, o anche peggio i nostri clienti,
la mia storia iniziale includeva l'organizzazione e la presidenza delle ispezioni di gruppo di sedute antiquate che mi hanno dato una visibilità notevolmente ampia a il nostro codice così riconosco il valore di vedere il codice di altre persone.

Impara, proteggi, fai squadra. Valori utili dalla partecipazione.

Probabilmente sai chi sono gli altri migliori ispettori. Probabilmente condividono il tuo interesse per l'ispezione, almeno un po '. Vedi se riesci a capire perché lo fanno o perché sono bravi e fai appello a quegli istinti. "Ho apportato alcune modifiche a questo complicato pezzo di codice e ho bisogno di qualcuno che lo controlli". O se sono solo giocatori di squadra "Ho bisogno che venga ispezionato in [un periodo di tempo specifico]. Potresti aiutarmi?"

Sono completamente d'accordo con quanto è stato detto in merito alla riluttanza a rivedere cose complicate e alla mancanza di incaricare qualcuno di essere responsabile - e non ho visto nulla nella tua domanda che indichi che tu e il tuo codice non siete desiderati dal vostro team! Penso piuttosto che il tuo team non abbia processi chiari su come gestire le recensioni.

Abbiamo parlato molto delle recensioni sul mio team. Forse alcune delle nostre conclusioni potrebbero essere utili a te e al tuo team:

• Cosa vogliamo da una recensione? Non (principalmente, almeno) stiamo cercando i piccoli dettagli. Vogliamo cogliere le insidie, le cattive scelte architettoniche e simili. Vogliamo anche scambiare buone idee e miglioramenti che potremmo essere in grado di individuare, ma questo è secondario.
• Poiché questo è ciò che vogliamo, ci vorrebbe troppo tempo per fare la revisione senza l'autore. Sarebbe come dover pensare dappertutto a tutti gli autori, ma senza il vantaggio di acquisire esperienza durante lo sviluppo!
• Anche se il commit è abbastanza semplice, non deve essere sparso su molti file prima che diventi difficile capire dove iniziare e dove finire, specialmente se questo non è "il tuo solito area del codice "
• Siamo sviluppatori esperti e, onestamente, di solito abbiamo una sensazione abbastanza buona su cosa sia l'area pericolosa e cosa sia probabilmente banale in quello che abbiamo appena fatto.
• Le recensioni sono un'ottima opportunità per condividere le conoscenze!
• La nostra soluzione: l'autore deve chiedere a uno o più membri del team di venire per una revisione. Questo può essere alla scrivania o in una riunione, a seconda dell'ambito. L'autore deve presentare ciò che ha fatto, quali scelte e quali compromessi sono stati fatti e perché, quindi i compagni di squadra forniscono un feedback. In questo modo la responsabilità ricade sull'autore e il revisore non deve capire tutto da solo: lo fa presentare da qualcuno che ha una panoramica e può rispondere a tutte le domande che possono sorgere lungo il suo percorso.

Aggiungerò che, a livello personale, siamo una squadra molto ben funzionante con un alto livello di fiducia. Non prendiamo personalmente il feedback e lo presentiamo in modo positivo e disarmante. Inoltre, se lavoriamo su cose complicate, discutiamo e discutiamo lungo la strada. In questo modo abbiamo una panoramica concettuale di ciò su cui stanno lavorando gli altri anche prima di dover rivedere il codice effettivo.

Anche se il tuo team non ha una strategia condivisa per le revisioni, puoi prendere idee da questo, se pensi che funzioneranno per te: allenati durante lo sviluppo, invita i compagni di squadra per le revisioni dove presenti - e assicurati di parlare loro dei dubbi e dei compromessi che hai avuto lungo la strada. Potrebbero effettivamente essere un po 'intimiditi da te se sei molto bravo, quindi se mostri loro che hai anche dei dubbi, potrebbero sentirsi più a loro agio con le recensioni.

• Riportalo durante una riunione regolare del team (se hai uno standup quotidiano o simile, ad esempio):
  • "Qualunque attività su cui sto lavorando è codice completo, ho bisogno di ottenerlo rivisto. "
• Proprio in quel momento, trova qualcuno che lo faccia:
  • " Chi può occuparsene / chi ha tempo / chi posso assegnare a? "
• Ottieni un impegno verbale, se possibile una sequenza temporale (prima di pranzo, entro le 3, nel corso della giornata, domani, ...)
  • "Grazie, lo unirò dopo, così possiamo rispettare tale o quella scadenza"
• Rendilo visibile in qualsiasi sistema tu stia utilizzando (ad esempio, in bitbucket, assegnare la persona come revisore)
• Riportalo durante lo stand-up se il tuo codice non è stato rivisto.
  • "Ragazzi, questo mi sta bloccando, altrimenti deve essere rivisto la funzione A non può essere spedita la prossima settimana "

Più tardi, discuti durante il retro (se ne hai) o una riunione ad hoc per spiegare che la revisione del codice fa parte del lavoro di tutti, che è un bene modo per sapere su cosa stanno lavorando gli altri, per imparare come funzionano, e che è necessario per il team e per fornire qualsiasi cosa, e così via - presumo che tu sappia a cosa servono le revisioni del codice :)

Ho entrambi avuto e sperimentato questo problema - in gran parte la causa principale è una o entrambe

• produci un grande volume di codice discutibilmente fine (il che significa che non hanno un input reale per esso oltre le banalità)
• il tuo stile di codice o la lingua di origine è molto poco familiare (il che significa che non sono sicuri nella loro revisione, peggio è la necessità di leggere pile di documentazione per capirlo)

Anche se esiste un motivo legale per richiedere revisori e non qualche capriccio del dipartimento, non preoccuparti direttamente delle loro recensioni , ma fornisci gli strumenti per aiutarli a rivedere il tuo codice - questo darà loro fiducia nella solidità del tuo codice nel suo insieme, piuttosto che setacciare ogni riga per errori assenti

• scrivere test per il tuo codice e richiedi revisioni sui test .. prova a scrivere una buona descrizione sullo scopo dei test
• chiedi e lavora con il tuo capo (?) per creare elementi di lavoro per prove contro funzionalità specifiche
• se possibile, raccogli la copertura per dimostrare che i test coprono tutti i rami che ti aspetti

Ciò renderà molto più facile per i tuoi colleghi rivedere ciò che tu hai scritto, perché avendo contribuito ai test e vedendo il buon risultato, avranno fiducia che funzioni!

Inoltre, prova a incontrarti regolarmente per fare in modo che tutti i membri mostrino qualcosa che pensavano fosse pulito durante la scorsa settimana (?). Vai per ultimo e assicurati di non divorare tutto il tempo - ce ne saranno di più e dovrebbero essere legittimamente interessanti, non un momento per mettersi in mostra o "insegnare" le tue cose. Ciò aiuterà a familiarizzare tutti con gli stili e gli strumenti degli altri che possono essere utilizzati per comprendere e sviluppare con la loro logica.