Come scegliere quale codice rivedere?

In generale, devi rivedere tutto . Se un'applicazione nuova ha 2 000 LOC, tutte le 2 000 LOC devono essere riviste.

Ecco perché non esiste una best practice su come scegliere cosa rivedere.

Se ti avvicini a un codebase di grandi dimensioni esistente, mai esaminato prima, allora è la stessa cosa quando devi riscrivere un codice numeroso esistente e scegliere da dove iniziare. Dipende strongmente:

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

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

• il tipo di recensione che fai (hai una lista di cose da recensire? A seconda degli elementi della checklist, potresti voler prima rivedere alcune parti).

Se fossi in te, vorrei:

• segui il principio dell'80% -20%, menzionato nel primo commento della seconda domanda a cui ti sei collegato.

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

• inizia con le parti del codice che usi di più e che sono le più importanti. Se il codebase ha una libreria che autentica e registra i nuovi utenti sul tuo sito web aziendale, rivedi prima, perché vuoi sicuramente trovare buchi nella sicurezza prima che gli hacker facciano.

• usa le metriche esistenti per determinare cosa è più importante rivedere. Se una parte della base di codice non ha affatto test unitari, mentre un'altra parte, ugualmente importante, ha una copertura del codice dell'85%, inizia esaminando 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, iniziare prima rivedendo il suo codice.

Inizia rivedendo tutte le modifiche apportate al codice; ciò impedirà che il problema peggiori. Quindi avviare la revisione del codice in base alla frequenza delle modifiche; queste saranno le aree "problematiche".

Dovresti trovare un modo per tenere traccia del fatto che hai esaminato una sezione di codice in modo da poter analizzare la copertura di revisione del tuo codice in relazione ad altri problemi.

Se puoi determinare quale codice non è coperto dai tuoi test, diventa prioritario per la revisione.

Verifica tutte le nuove modifiche apportate prima di passare alla produzione. script di installazione, codice sorgente, modifiche al database, tutto! L'intero punto di revisione del codice è quello di impedire al codice errato di trasformarlo in produzione. Che si tratti di un cattivo schema organizzativo 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 esaminando il codice, se in una classe c'era un codice duplicato che conteneva una correzione di bug, anche se lo sviluppatore non ha modificato quel codice nella sua correzione, non l'avrei passato. Li farei tornare indietro e rimuovere il codice duplicato.

Se rifattori incessantemente, la revisione del codice diventa utile. Altrimenti è una perdita di tempo.

Se incorpori il processo di revisione del codice come fase del tuo processo di sviluppo, il codice base migliorerà nel tempo. Ancora meglio, non dovresti consentire ai tuoi sviluppatori di svolgere nuove funzioni o correzioni di bug fino a quando il backlog di revisione del codice non è vuoto. Ciò garantisce che la revisione del codice venga eseguita.

Se ci sono aree note che devono essere sottoposte a refactoring, ma ci vorrà molto tempo per eseguirle (vale a dire 1 settimana o più). Quindi crea un elemento 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 del boyscout. Lascia il codice meglio di come l'ha trovato.

Questo non significa che devi correggere l'intero file per essere perfetto. Ma non dovrebbe aggiungere confusione, dovrebbe migliorare un po '. Forse spostando le modifiche in nuove classi che sono strutturate correttamente e lasciando il resto del codice originale come (dopotutto, è "funzionante").

Quando inizi a migliorare il codice esaminando tutto il nuovo codice e le modifiche, come sviluppatori, devi sapere quali aree dell'applicazione richiedono il maggior numero di modifiche. Quindi, rivedi quelli, parla di come possono essere migliorati, a poco a poco.

Revisione del codice scritto 10 anni fa, per motivi di revisione, è inutile, lo sviluppatore dovrebbe essere migliorato in questi 10 anni. Quindi, non ha senso rivederlo solo per imparare ciò che sapete tutti.

Lo scopo delle revisioni del codice è quello di migliorare e correggere gli errori che stai facendo attualmente e di condividere quelle conoscenze tra i membri del team.

Nel mio progetto includiamo la revisione del codice come un must-have nella maggior parte dei casi per qualsiasi compito / user story / bug sviluppato. Stiamo utilizzando i processi scrum / agile e ticket / story non viene spostato su built (che è un backlog per QA) fino a quando non vengono scritti i test unitari e completata la revisione del codice.

Utilizziamo Atlassian FishEye analisi 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 lascia i commenti per la specifica riga di codice) lo sviluppatore corregge i problemi citati / implementa i miglioramenti suggeriti e sposta il ticket nella colonna Costruita in JIRA - che significa che la storia è pronta per essere testata e che non ci sono più modifiche al codice previste per questo specifico oggetto di lavoro.

Ciò garantisce anche che il controllo qualità non sottopone a test nulla che potrebbe essere modificato e potrebbe essere interrotto 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.