Come faccio a scegliere quale codice rivedere?

Faccio parte di un team di sette sviluppatori in una piccola società di software e sto cercando di introdurre periodicamente codici di gruppo e revisioni di progettazione. Abbiamo effettuato alcune recensioni in passato, ma è stato sporadico. Vorrei renderlo una cosa più regolare.

Ho letto Code Complete e altre risorse simili e parlano dei meccanismi di come eseguire le revisioni del codice, ma non sono stato in grado di trovare le migliori pratiche su come scegliere cosa rivedere. Abbiamo una base di codice che ha più di otto anni e copre una varietà di lingue, quindi ce ne sono molte che potrebbero essere esaminate.

Ecco alcuni dei fattori a cui posso pensare che potrebbero influenzare la scelta:

• Lingua: C, Java, SQL, PL / SQL
• Età del codice: nuovo codice vs vecchio codice
• Utilizzo del codice: codice usato frequentemente vs (effettivamente) codice morto / poco usato
• Importanza del codice: codice critico vs codice non critico
• Sviluppatore: codice sviluppatore junior vs codice sviluppatore senior

Capisco che questa non è una domanda con una risposta definitiva assoluta, ma qualsiasi guida sarebbe utile.

Alcune domande relative alla periferia:

• Approcci di revisione del codice (menzioni di revisione delle sezioni critiche e nuovo codice per gli sviluppatori)
• Dovremmo tentare di rivedere tutto il nostro codice?

In generale, è necessario rivedere tutto . Se una nuova domanda ha 2 000 LOC, tutti i 2 000 LOC devono essere rivisti.

Ecco perché non esiste una migliore pratica su come scegliere cosa rivedere.

Se ti avvicini a una base di codice di grandi dimensioni esistente, mai esaminata prima, è la stessa cosa quando devi riscrivere una base di codice di grandi dimensioni esistente e scegliere da dove iniziare. Dipende fortemente:

• sulla base di codice (un singolo codice monolitico sarebbe più difficile da riscrivere / rivedere rispetto a un insieme di componenti separati, ecc.),

• il tuo contesto (puoi interrompere tutto ciò su cui lavori e trascorrere tre mesi (tre anni?) lavorando solo su riscrittura / revisione, oppure devi farlo a piccoli intervalli, solo quando hai tempo libero)?

• il tipo di revisione che fai (hai un elenco di controllo delle cose da rivedere? A seconda degli elementi dell'elenco di controllo, potresti voler prima esaminare alcune parti).

Se fossi in te lo farei:

• seguire il principio 80% -20%, menzionato nel primo commento della seconda domanda a cui si è collegati.

• tieni conto che il 100%, essendo un ideale, non ne vale la pena. È come una copertura del codice al 100% per i test unitari, tranne per il fatto che tale copertura del codice è per lo più impossibile o estremamente costosa.

• inizia con le parti del codice che usi di più e quali sono le più importanti. Se la base di codice ha una libreria che autentica e registra i nuovi utenti sul tuo sito Web aziendale, esaminalo prima, perché desideri sicuramente trovare falle nella sicurezza prima degli hacker.

• utilizzare le metriche esistenti per determinare cosa è più importante rivedere. Se una parte del codebase non ha affatto test unitari, mentre un'altra, altrettanto importante, ha una copertura del codice dell'85%, iniziare rivedendo la prima parte. Se una parte della base di codice è stata scritta da uno sviluppatore che era noto per essere inesperto e per introdurre più bug di tutti i suoi colleghi, inizia prima rivedendo il suo codice.

Inizia esaminando tutte le modifiche apportate al codice; questo eviterà che il problema peggiori. Quindi iniziare a rivedere il codice in base alla frequenza delle modifiche; queste saranno le aree "problematiche".

Ti consigliamo di trovare un modo per monitorare che hai esaminato una sezione di codice in modo da poter analizzare la copertura di revisione del tuo codice rispetto ad altri problemi.

Se riesci a determinare quale codice non è coperto dai tuoi test, questa diventa una priorità più alta per la revisione.

Rivedi tutte le nuove modifiche che sono state apportate prima che arrivino alla produzione. script di installazione, codice sorgente, modifiche al database, tutto! L'intero punto della revisione del codice è quello di impedire che il cattivo codice lo trasformi in produzione. Che si tratti di uno schema organizzativo scadente o semplicemente di un bug introdotto perché qualcosa è mancato.

Il refactoring del codice corrente su cui stai lavorando va di pari passo con la revisione del codice. Ad esempio, quando sto rivedendo il codice, se in una classe fosse presente un codice duplicato che conteneva una correzione di bug, anche se lo sviluppatore non avesse modificato quel codice nella correzione, non lo avrei passato. Vorrei tornare indietro e rimuovere il codice duplicato.

Se si esegue il refactoring senza sosta, la revisione del codice diventa utile. Altrimenti è una perdita di tempo.

Se si incorpora il processo di revisione del codice come passaggio nel processo di sviluppo, la base di codice migliorerà nel tempo. Meglio ancora, non dovresti permettere ai tuoi sviluppatori di accettare nuove funzionalità o correzioni di bug fino a quando il backlog di revisione del codice non è vuoto. Ciò garantisce che venga eseguita la revisione del codice.

Se ci sono aree conosciute che devono essere rifattorizzate, ma ci vorrà molto tempo per realizzarle (cioè 1 settimana o più). Quindi crea un oggetto di lavoro per quel refactoring da solo e aggiungilo come oggetto su cui lavorare.

Inizia esaminando tutto il nuovo codice e le modifiche al codice esistente.

Durante la revisione delle modifiche al codice esistente, lo sviluppatore dovrebbe seguire la regola boyscout. Lascia il codice meglio di come lo ha trovato.

Ciò non significa che devi correggere l'intero file per essere perfetto. Ma non dovrebbe aggiungere al caos, dovrebbe renderlo un po 'meglio. Forse spostando le modifiche in nuove classi che sono adeguatamente strutturate e lasciando il resto del file di codice originale così com'è (dopo tutto, funziona).

Una volta che inizi a migliorare il codice esaminando tutto il nuovo codice e le modifiche, come sviluppatori, dovresti sapere quali aree dell'applicazione richiedono il maggior numero di modifiche. Quindi, rivedi quelli, discuti su come possono essere migliorati, a poco a poco.

Revisionare il codice scritto 10 anni fa, per motivi di revisione, non ha senso, lo sviluppatore avrebbe dovuto migliorare in questi 10 anni. Quindi, non ha senso rivederlo solo per imparare ciò che tutti sapete.

Lo scopo delle revisioni del codice è migliorare e correggere gli errori che stai commettendo e condividere tali conoscenze tra il team.

Nel mio progetto includiamo la revisione del codice come un must nella maggior parte dei casi per qualsiasi compito / storia utente / bug sviluppato. Stiamo usando scrum / processi agili e ticket / story non vengono spostati su build (ovvero un backlog per il QA) fino a quando i test unitari non vengono scritti e la revisione del codice non viene completata.

Usiamo l' analisi Atlassian FishEye con la revisione del codice Crucible integrata con JIRA + SVN per questo scopo.

Quando lo sviluppatore controlla il codice per una storia specifica, crea una nuova revisione del codice in FishEye, dove seleziona gli altri membri del team per fare la revisione.

Una volta completata la revisione del codice (lo strumento evidenzia le modifiche inviate e consente di lasciare i commenti per la specifica riga di codice) lo sviluppatore corregge i problemi citati / implementa i miglioramenti suggeriti e sposta il ticket nella colonna Costruito in JIRA - ciò significa che la storia è pronto per essere testato e che non ci sono più modifiche al codice previste per questo specifico oggetto di lavoro.

Ciò garantisce anche che il QA non verifichi nulla che possa essere modificato e potenzialmente rotto durante il refactoring del codice dopo la revisione del codice .

Per riassumere, tutto il codice deve essere rivisto - questo supporta l'alta qualità del codice, che di solito si traduce in una migliore progettazione, leggibilità, manutenibilità e testabilità del codice e migliora le prestazioni di sviluppo a lungo termine.