Qual è una mentalità utile quando si esegue una revisione formale del codice

Il nostro team ha recentemente iniziato a condurre revisioni del codice per ogni check-in.

Come capo del team sto cercando di trovare un equilibrio tra fornire troppi suggerimenti, fastidiosi sviluppatori e ridurre l'output dei team e lasciare andare il codice che avrei scritto diversamente.

Esistono prove, studi o indicazioni da fonti ben note che suggeriscono un approccio utile?

Tieni a mente gli obiettivi generali: alla fine, conta solo il software funzionante

Revisione tra pari e revisione del codice di check-in hanno l'obiettivo di migliorare la qualità . Ma non c'è niente di peggio per la qualità di uno sviluppatore demotivato. Come team leader, il tuo ruolo non è quello di approvare il codice come qualcosa che avresti potuto scrivere da solo, ma di promuovere il lavoro di squadra e garantire il risultato complessivo.

Imposta un ambito chiaro per la tua recensione

Ricorda: non è il tuo codice, ma il codice del team. Quindi, concentrati su cose che potrebbero portare a risultati sbagliati.

• Non sfidare il modo in cui lo sviluppatore ha scelto di soddisfare i requisiti, a meno che tu non sia sicuro che non funzionerà (ma non dovrebbe aver già fallito i test, no?)

• Non sfidare per prestazioni scadenti a meno che non ci sia una misura che mostri dove si trova il problema. L'ottimizzazione prematura è la radice di tutti i mali ;-)

• Se trovi un design o una struttura software da sfidare, allora chiediti perché non è stato scoperto in anticipo! Il codice già scritto è costoso da riscrivere. In tal caso, è il momento di rivedere lo sviluppo del software e le pratiche di lavoro di squadra almeno quanto il codice.

• indirizzare la conformità con gli standard di codifica stabiliti. È l'argomento più fastidioso da discutere sia per il recensore che per il recensore. Quando tutti hanno accettato di usare nomi di classe in maiuscolo nella tua squadra e un ragazzo ha una classe senza, è una questione di gusti? O dell'efficacia e del rischio del lavoro di squadra?

A proposito, se ritieni che non valga la pena discutere di uno standard di codifica, rimuovilo dai tuoi standard e non perdere tempo ed energia su di esso.

Sviluppare la leadership: il lato umano della recensione

Come team leader, potresti trovare qui un'opportunità per sviluppare te stesso e il tuo team, oltre la formalità di un controllo di qualità:

• Le revisioni del codice sono molto più piacevoli per tutti, se c'è un vero scambio. Dai anche al tuo sviluppatore l'opportunità di mostrare le loro abilità (e sì, forse potresti imparare qualcosa di nuovo).
• Avere un orecchio aperto alle critiche sulle scelte di progettazione o sugli standard esistenti. A volte le persone possono affrontare meglio queste frustrazioni, solo perché ne possono parlare.
• Allena i tuoi ragazzi: non esitare a dare consigli o orientamenti di refactoring per la prossima iterazione. Non farlo con gli anziani: in un altro mondo il tuo ruolo potrebbe essere cambiato.

Approfitta di altre pratiche

Ci sono un paio di cose che puoi evitare nella revisione del codice:

• L'uso di un analizzatore di codice statico nella catena di build può automatizzare la ricerca di bug comuni o costrutti non portatili, molto prima della revisione tra pari. Alcuni strumenti possono persino verificare alcuni dei tuoi standard di codifica .
• Se hai standard sul layout del codice, usa un pre-commit pretty-print o formattatori simili per formattare il codice come richiesto automaticamente. Non perdere mai tempo in qualcosa che un software potrebbe fare per te meglio e senza discutere :-)
• Infine, la qualità non è garantita solo dalla revisione, ma anche dai test. Se non usi ancora TDD , pensaci indipendentemente dalla revisione del codice.

Come sviluppatori siamo, la mentalità dovrebbe rimanere sempre aperta e scettica allo stesso tempo.

Aperti, perché non sappiamo quando uno sviluppatore potrebbe sorprenderci e scettici sulle nostre idee perché spesso dimentichiamo che nell'ingegneria del software non esiste un solo modo corretto per implementare una soluzione. La logica alla base delle nostre soluzioni potrebbe avere senso per noi e non averne nessuno per gli altri. Dietro un odore di codice potrebbe esserci una grande idea. Forse lo sviluppatore non ha trovato il modo di esprimerlo correttamente.

A causa nostra (umani) siamo terribili nel comunicare, non fare false assunzioni, sii disposto a chiedere al proprietario del codice il codice che stai esaminando. Se non riesce a codificare l'idea sotto gli standard dell'azienda, come sviluppatore principale sarà disposto a guidare anche lui / lei.

Qui l'approccio soggettivo. L'approccio oggettivo, IMO, è molto ben spiegato in questa domanda .

Oltre al link sopra, l'insieme di obiettivi da raggiungere (manutenibilità, leggibilità, portabilità, elevata coesione, accoppiamento lento, ecc.) Non sono necessariamente i Dieci Comandamenti. Tu (il team) dovresti essere in grado di adattare questi obiettivi a un punto in cui l'equilibrio tra qualità e produttività rende il lavoro confortevole e "abitabile per gli sviluppatori".

Suggerirei l'uso di strumenti di analisi del codice statico per misurare il progresso della qualità in base a questi obiettivi. Strumenti come SonarQube ci forniscono cancelli di qualità e profili di qualità che possono essere personalizzati in base alle nostre priorità. Ci fornisce anche un tracker di problemi, in cui gli sviluppatori possono essere presi di mira con problemi relativi a odore di codice, bug, pratiche dubbie, ecc.

Questo tipo di strumenti può essere un buon punto di partenza, ma come ho detto mantieniti scettico. Potresti trovare alcune regole in Sonar per te insignificanti, quindi sentiti libero di ignorarle o rimuoverle dal tuo profilo di qualità.

Ingerire con il codice dello sviluppatore per i cambiamenti estetici demotivherà lo sviluppatore, ma in circostanze assolute deve essere fatto. Il vantaggio deve trovare l'equilibrio tra fornire un'utile revisione del codice e imparare a liberarsi delle carenze minori. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Alcune cose da tenere a mente:

1. Riguarda la psicologia quanto la tecnologia, quindi non esiste una regola d'oro qui.
2. Ciò che riguarda le persone non riguarda solo la conoscenza, ma anche la cultura e la posizione nella gerarchia.
3. Se si tratta di un gioco "lungo" (società stabile e consolidata), un team ben integrato in cui le persone si fidano reciprocamente di solito ha un valore superiore rispetto al codice in esame. Non dovrebbe essere usato per forzare cose che non sono assolutamente necessarie per procedere. Il diavolo è nei dettagli ...
4. Se si tratta di un gioco "corto" (progetto collaterale, ricerca e sviluppo, molti liberi professionisti in un gruppo) i costi di CR spesso superano gli avventuri che provengono dal loro svolgimento. E l'atteggiamento dovrebbe essere "basta farlo svegliare"

Ci sono solo due cose che contano.

1. Esistono test automatici per tutti i requisiti?
2. Passano tutti?

Tutto il resto è cosmetico e dovrebbe essere discusso sulla birra piuttosto che forzato come un cancello.

Se segui questa vista, ti limita a una ristretta area di messa a fuoco.

I requisiti sono buoni? Che idealmente dovresti sapere prima di iniziare l'attività, ad esempio prestazioni, sicurezza ecc. Dovrebbero essere tutti lì dentro

I test sono buoni test? Eventuali casi limite persi, stanno testando bene il requisito ecc. In definitiva: puoi scrivere un test che è per un requisito esistente ma che fallirà?