Come gestire nessuna recensione di codice nel mio nuovo posto quando provengo da quella pratica?

Il team della mia nuova società non ha un processo di revisione del codice.

Vengo da aziende con la revisione del codice come cultura indispensabile e quindi non mi sento a mio agio a commettere il mio codice senza averlo revisionato da qualcuno.

Sono fermamente convinto che la revisione del codice sia un modo per migliorare la qualità e risparmiare tempo perché rileva potenziali problemi in precedenza (nota che non sto parlando di programmazione di coppie).

• Come posso dimostrare che la revisione del codice non è una perdita di tempo ma un risparmio di tempo?
• È possibile saltare la revisione del codice se si dispone di unit test?

È possibile saltare la revisione del codice se si dispone di unit test?

Ma perché?

Il ruolo principale della revisione tra pari non è quello di individuare i bug.

Sì, potresti identificare alcuni potenziali bug e un codice dubbio e soggetto a bug, ciò accade spesso, ma occasionalmente individuare alcuni errori non significa che la revisione tra pari sia un modo affidabile per escludere la presenza di bug. Lontano da quello. Non è lo strumento giusto per verificare la correttezza funzionale dell'implementazione.

La revisione del codice impone tuttavia la manutenibilità del codice . Chiederò che il codice sia pulito e comprensibile (non solo per il suo autore) prima che entri in produzione.

La presenza di unit test è completamente ortogonale a quella. Puoi avere una copertura del codice del 100% e passare tutti i test per un codice totalmente incomprensibile.

La revisione del codice serve anche a familiarizzare altri sviluppatori con il tuo lavoro in modo che sappiano cosa è cosa e sono in grado di raccogliere da lì, o gestire segnalazioni di bug mentre sei in vacanza, ecc. Sapere cosa hai fatto subito può aiutarli fanno bene il loro lavoro - mantieni coerente la base di codice (attenersi a schemi e convenzioni simili in tutta l'app) o evitare la duplicazione del codice.

In un più ampio schema di cose, si impara e cresce anche come sviluppatore leggendo il codice di altre persone.

I test unitari non possono essere una sostituzione per nessuno di questi. Sì, se sono ben scritti, leggono come documentazione e dovremmo impegnarci per questo. Ma ancora una volta questo non si esclude a vicenda con l'esecuzione di peer review, anzi: tutti i vantaggi della peer review sono ancora veri, il fatto che i tuoi coetanei abbiano dei bei test unitari da guardare renderà il processo di revisione più semplice e persino più vantaggioso piuttosto che ridondante.

Ci sono studi e statistiche che mostrano che la revisione del codice non è una perdita di tempo ma un risparmio di tempo?

Non ne conosco nessuno. È anche difficile condurre tali studi, perché avresti bisogno di due team che hanno un compito di uguale e realistica complessità da realizzare, in cui uno utilizza le revisioni del codice e l'altro no. Probabilmente avresti bisogno che risolvessero lo stesso problema, il che significa buttare un sacco di soldi fuori dalla finestra. E avresti bisogno di ripetere l'esperimento abbastanza spesso per ottenere rilevanza statistica, il che aumenterebbe i soldi lanciati da ordini di grandezza.

Se si misura semplicemente l'efficienza delle aziende che utilizzano revisioni del codice rispetto alle aziende che non lo fanno, non è solo chiaro come misurare l'efficienza, ma anche quale sia la vera causa. Le revisioni del codice fanno parte di una cultura più ampia. Quale parte di essa rende il team più efficiente è difficile da dire (e può benissimo dipendere dalla natura del team o del progetto). Oppure la presenza di questa cultura può semplicemente significare che l'azienda è più piccola o più giovane, ognuna delle quali ha molti effetti. O potrebbe anche essere che la volontà di sottomettersi alle revisioni del codice precluda o promuova una sana distanza dal tuo ego;)

Ma non dimenticare: hai la tua esperienza da cui attingere. Fa parte del perché ti hanno assunto. Quindi, se credi davvero di poter aumentare l'efficienza (e il tuo team ne soffre effettivamente una mancanza), allora comunicalo chiaramente.

È possibile saltare la revisione del codice se si dispone di unit test?

No. Se credi nell'importanza dei test, in realtà i tuoi test dovrebbero essere la prima cosa da rivedere. E se fossero sciocchezze? O se la copertura è scadente? O se testano l'implementazione piuttosto che il comportamento?

Tratto da alcune diapositive casuali che ho trovato , ma i dati concreti provengono dal libro Codice completo di Steve McConnell:

Le recensioni di codice sono utili?

"Credo che le revisioni del codice peer siano la cosa più grande che puoi fare per migliorare il tuo codice"

Jeff Atwood di Coding Horror su http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

"Le ispezioni individuali rilevano in genere circa il 60 percento dei difetti, che è superiore rispetto ad altre tecniche tranne la prototipazione e il beta testing ad alto volume".

Steve McConnell, Code Complete 2nd Edition, pagina 485

Tale cifra del 60% proviene dall'articolo IEEE di Shull et al 2002 Cosa abbiamo imparato sui difetti di combattimento che contiene la sezione intitolata:

"Le revisioni tra pari rilevano il 60% dei difetti"

Disclaimer: questa risposta è la mia esperienza personale :)

Ho fatto delle pessime esperienze con le revisioni del codice nel codice che manteniamo. Perché di solito abbiamo solo una fodera e non c'è molto da rivedere.

Ma in progetti concreti ho fatto buone esperienze, durante il mio tempo d'esame il mio allenatore ha rivisto il mio codice e mi ha aiutato molto a trovare alcuni errori che ho fatto molto spesso, che non faccio più.

Quindi direi che dipende molto da cosa stai facendo, da quante persone sei ecc.

Inoltre, il rischio che le tue visualizzazioni in codice terminino in una guerra non è da sottovalutare.

Potresti chiedere al tuo team leader e / o collega di rivedere il tuo codice, anche se le revisioni del codice non vengono eseguite normalmente, forse come parte della tua formazione.

Assicurati che il tuo codice sia ben scritto e testato prima della revisione.

Quando ero un caposquadra ero solito fare delle revisioni del codice di nuovi dipendenti, fino a quando (dopo un po ') smettevo di trovare bug o qualsiasi altra cosa da criticare nel loro codice, e su quale punto avrei smesso di fare revisioni del codice con loro; ciò accadrebbe quando:

• Hanno imparato i sistemi con cui si interfacciano e non hanno avuto bisogno delle mie spiegazioni al riguardo
• Hanno imparato a progettare e / o testare il loro codice fino a quando non è stato privo di bug prima che lo vedessi
• Hanno imparato abbastanza sulle mie linee guida sullo stile di codifica che considererei il loro codice mantenibile

Le revisioni del codice hanno diversi scopi:

• Individuazione di difetti nel codice
• Trasferimento di conoscenze tra i membri del team

Penso che vada bene fare revisioni del codice di nuovi dipendenti, anche se il team sceglie di saltare le revisioni del codice tra i membri esperti del team.

Non esiste una regola empirica per le revisioni del codice da eseguire su qualsiasi software sviluppato ... tutto dipende dall'ambito dell'applicazione, dalle dimensioni del client e dalle dimensioni dell'azienda. Ad esempio, se si sta creando un'applicazione in cui si tratta di un'applicazione semplice in cui potrebbero non essere implementate ulteriori versioni in futuro, il test unitario è sufficiente lì. Ma ancora una volta la revisione del codice ha luogo quando si parla di prestazioni dell'applicazione in cui è necessario rivedere il codice per qualsiasi breve caduta del codice che avrebbe potuto essere fatto in un modo migliore per facilitare prestazioni più veloci.

Le revisioni del codice vengono generalmente eseguite in presenza di un team di più di 2 sviluppatori e di un responsabile tecnico in cui il responsabile tecnico desidera garantire la qualità dell'applicazione e assicurarsi che vengano seguiti gli standard del codice per ridimensionare l'applicazione per futuri miglioramenti e aggiornarla per diversi prossime versioni.

Ad esempio, ora disponiamo di molte piattaforme open source CMS e queste piattaforme rilasciano periodicamente aggiornamenti per migliorare le funzionalità della piattaforma, immaginiamo uno sviluppatore che utilizza una di queste piattaforme e non ha seguito gli standard del codice come la codifica hardware nei file core, la scrittura di applicazioni codice nei file modello, e se questo codice va in produzione e successivamente quando il client desidera aggiornare la piattaforma alla nuova versione, non verrà mai aggiornato a meno che la codifica non venga rifatta secondo gli standard di codice per quella piattaforma. Qui diventa un grave problema per il rilascio del codice in produzione senza revisione del codice.

Quindi direi che fare revisioni del codice prima del rilascio è un must per qualsiasi azienda di software professionale e le eccezioni possono essere solo per applicazioni personali / su scala molto piccola in cui lo sviluppatore è programmatore molto esperto e porta esperienza con lui.

Le revisioni del codice presentano vantaggi che non derivano dal processo di revisione stesso: esiste sempre un dilemma per ottenere codice di alta qualità, ma creato in breve tempo. Senza le revisioni del codice, sei da solo, quindi potresti sacrificare la qualità per eseguire il codice in breve tempo. Con le revisioni del codice, c'è questo recensore che non ti consente di cavartela con una bassa qualità del codice - che è esattamente quello che vuoi, essendo costretto a passare il tempo per ottenere il codice di qualità che è quello che volevi in ​​primo luogo, e che sai, finirai per risparmiare tempo perché ogni ora impiegata per scrivere un codice migliore risparmia due ore sul debugging (o più).

Senza la revisione del codice, sei da solo, quindi spetta a te mantenere un'alta qualità del codice. Una soluzione semplice è quella di rivedere ogni cambiamento apportato a te stesso e risolvere cose che non sono all'altezza dei tuoi standard di qualità.

Ciò evita anche situazioni orribili in cui le revisioni del codice portano a scontri di ego: la situazione in cui il programmatore A utilizza il metodo X, mentre B utilizza il metodo Y, quindi se A scrive il codice utilizza il metodo X, il revisore B insiste sul metodo Y, quindi A riscrive il codice usando il metodo Y, mentre se B avesse scritto il codice e A lo avesse verificato, sarebbe successo esattamente l'opposto.

Se sei un sostenitore delle revisioni del codice, temo non ci sia un vero sostituto. Il caso sfortunato e stereotipato è un posto di lavoro che non fa revisioni del codice perché (A) non hanno familiarità con la pratica e / o (B) non vogliono dedicare il tempo e gli sforzi per ottenere una revisione del codice sistema in atto.

Fondamentalmente, per ottenere quello che vuoi qui, hai bisogno di un cambiamento nella cultura del posto di lavoro - e questo non è mai semplice o facile. Non dimenticare che anche se il tuo posto di lavoro è convinto al 100% che le revisioni del codice sono eccellenti e vogliono adottarle, il passaggio al nuovo modo di lavorare richiederà comunque un investimento significativo di tempo, energia e produttività. Questo investimento dovrebbe ripagarsi, ma è necessario disporre di buy-in per l'investimento, non solo per il payoff. Guarda il video di Roy Osherove "Unit Testing e TDD - How To Make It Happen" - le sfide dell'adozione delle revisioni del codice sono molto simili a quelle dell'adozione dei test unitari.

Nel frattempo, fai quello che puoi per ottenere il più possibile:

• Se ci sono altri sviluppatori che vedono il valore delle revisioni del codice, prova a esaminarle reciprocamente, anche in modo informale.
• Se hai un mentore o uno sviluppatore responsabile della tua formazione, spiegagli il valore che vedi nelle revisioni del codice e chiedi se sarebbero disposti a rivedere il tuo codice, almeno a volte.
• Di 'al tuo manager che vorresti rivedere il codice di altre persone, perché ti aiuterà a capire meglio il sistema.
• Se a un certo punto diventi un leader del team, puoi installare revisioni del codice a livello locale, solo per il tuo team.

Uno dei maggiori vantaggi di uno di questi è che, se riesci a mantenerli nel tempo, allora gli sviluppatori intorno a te inizieranno a notare le recensioni del codice. Dimostrerai efficacemente come le revisioni del codice possono essere integrate nella cultura esistente e questo aprirà la strada affinché la cultura inizi a cambiare. Le revisioni del codice aiutano , quindi se sei in grado di dimostrarlo su piccola scala, questo aprirà la strada agli altri - e alla cultura nel suo insieme - per seguire il tuo esempio.

Smetti di preoccuparti: il tuo nuovo datore di lavoro non si preoccupa delle revisioni del codice. Impara ad avere un po 'di fiducia nelle tue capacità senza che qualcun altro ti dica che va bene controllare il codice che hai scritto. Presto imparerai a vivere senza il processo noiosamente noioso che sta rivedendo il codice di altre persone.

Segui le linee guida di stile (o solo lo stile) che tutti gli altri usano. Usa la tua esperienza per decidere cosa deve essere commentato, quali convenzioni di denominazione usare e così via.

Quindi prova tutto prima di registrarlo. La cosa più importante è che funzioni correttamente.

Se al tuo nuovo datore di lavoro non piace l'idea delle revisioni del codice, potrebbe essere perché hanno un'associazione negativa con metodologie di comando e controllo vecchio stile e mirano a un insieme di pratiche di tipo più moderno e agile. In questo caso, potrebbero essere più aperti all'idea della programmazione in coppia, che offre molti degli stessi vantaggi ed è ampiamente considerata come una pratica più dinamica e moderna.