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

Tieni presenti gli obiettivi generali: alla fine, solo le questioni relative al software di lavoro

La revisione paritaria e la 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 per 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 della squadra. 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 avrebbe già dovuto fallire i test, no?)

• Non sfidare per le scarse prestazioni a meno che non ci sia una misura che mostri dove si trova il problema. L'ottimizzazione prematura è la radice di tutto il male ;-)

• Se trovi un progetto o una struttura software da sfidare, chiedi a te stesso perché non è stato catturato in anticipo! Il codice già scritto è costoso da riscrivere. Se ciò accade, è il momento di rivedere lo sviluppo del software e le pratiche di lavoro di squadra almeno quanto il codice.

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

A proposito, se ritieni che uno standard di codifica non valga la pena di essere discusso, rimuovilo dai tuoi standard e non sprecare tempo ed energie su di esso.

Sviluppa la leadership: il lato umano della recensione

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

• Le recensioni dei codici sono molto più piacevoli per tutti, se c'è un vero scambio. Offri al tuo sviluppatore l'opportunità anche 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 far fronte meglio a tali frustrazioni, solo perché potrebbero parlarne.
• Allena i tuoi juniores: non esitare a dare consigli o orientamenti per il refactoring per la prossima iterazione. Non farlo con gli anziani: in un altro mondo il tuo ruolo potrebbe essere cambiato.

Approfitta delle altre pratiche

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

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

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

Aperto, perché non sappiamo quando uno sviluppatore può sorprenderci e scettico sulle nostre idee perché spesso dimentichiamo che nella tecnologia del software non esiste un unico modo corretto per implementare una soluzione. La logica alla base delle nostre soluzioni potrebbe avere senso per noi e non renderla 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 di noi (umani) siamo terribili nel comunicare, non fare false assunzioni, essere disposti a chiedere al proprietario del codice il codice che si sta esaminando. Se non è riuscito a codificare l'idea sotto gli standard dell'azienda, come lo sviluppatore principale è disposto a guidarlo anche lui.

Ecco l'approccio soggettivo. L'approccio obiettivo, IMO, è spiegato molto bene in questa domanda .

Oltre al link sopra, l'insieme degli obiettivi da raggiungere (manutenibilità, leggibilità, portabilità, alta coesione, accoppiamento libero, 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 constrongvole 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à. Fornisce inoltre un tracker dei problemi, in cui gli sviluppatori possono essere indirizzati a problemi relativi a odore di codice, bug, pratiche dubbiose, 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 essere prive di significato per te, quindi sentiti libero di ignorarle o rimuoverle dal tuo profilo di qualità.

Interessarsi con il codice dello sviluppatore per modifiche estetiche demotiverà lo sviluppatore, ma in circostanze assolute deve essere fatto. Il ruolo guida deve trovare l'equilibrio tra fornire analisi del codice utile e imparare a lasciar andare delle piccole imperfezioni. link

Alcune cose da tenere a mente:

1. Riguarda sia la psicologia che la tecnologia, quindi qui non esiste una regola d'oro.
2. Quello 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" (azienda 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 questo è un gioco "corto" (progetto collaterale, R & D, molti freelance in un gruppo), i costi di CR spesso superano gli adventages che provengono dal farli. E l'atteggiamento dovrebbe essere "basta farlo wok"

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, allora ti limita a una ristretta area di messa a fuoco.

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

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