Code Review: standard, checklist e strumenti
Nel contesto dello sviluppo del software, la revisione del codice è una delle fasi cruciali del ciclo di vita di sviluppo del software (SDLC): rappresenta infatti un aspetto fondamentale per identificare potenziali minacce e vulnerabilità nel codice. In altre parole, è estremamente importante per il successo di ogni progetto sviluppo. In questo articolo vediamo quali sono gli standard della code review secondo le linee guida stabilite da Google, per poi esplorare una checklist esaustiva con tutti gli elementi rilevanti da considerare durante la revisione del codice, accompagnata dall’analisi degli strumenti essenziali che facilitano questo processo cruciale.
Che cos’è la revisione del codice
Come suggerisce il nome, la revisione del codice è un processo in cui uno più sviluppatori esaminano il codice scritto da un altro sviluppatore (l’autore del codice), per assicurarsi che:
- Il codice non abbia nessun errore, non ci sono bug o problemi che possano comprometterne il funzionamento
- Sia conforme ai princìpi di qualità, ai requisiti e agli standard stilistici stabiliti
- Funzioni come dovrebbe
- Migliori la codebase dopo l’integrazione
Quest’ultima caratteristica è fondamentale: il revisore del codice assume il ruolo di valutatore determinante per stabilire se il codice proposto può essere integrato nel codebase esistente e successivamente avviato in produzione.
Ad esempio, Google (Fonte) si avvale di precisi standard per la revisione del codice che sottolineano specifici criteri da considerare durante questo processo. Secondo la documentazione di Google
“Lo scopo principale della revisione del codice è assicurare un miglioramento continuo della qualità del codice nella codebase di Google nel corso del tempo.”
— Google’s Engineering Practices documentation
Gli standard Google della code review
Per raggiungere l’obiettivo appena citato, è necessario trovare un equilibrio tra diversi compromessi.
Prima di tutto gli sviluppatori devono essere in grado di fare progressi in modo continuo: l’assenza di proposte di miglioramento nella codebase impedisce il suo sviluppo e avanzamento. Inoltre, se il revisore del codice rende eccessivamente complesso il processo di presentazione di un cambiamento o di una nuova implementazione nel codice, potrebbe disincentivare gli sviluppatori dall’introduzione di miglioramenti futuri.
Dall’altra parte, è dovere del reviewer fare in modo che ogni changelist rispetti standard di qualità tali da non compromettere la salute generale del codice sorgente.
Questo compito può risultare impegnativo in quanto anche piccoli deterioramenti nella qualità del codice possono causare una progressiva degradazione della codebase, soprattutto quando il team è sotto pressione e sente la necessità di adottare scorciatoie per raggiungere gli obiettivi.
Un reviewer ha inoltre la responsabilità del codice che sta revisionando: è compito suo assicurarsi che la codebase abbia le seguenti caratteristiche:
- Ben sviluppata
- Funzionalità ottimale per gli utenti del codice
- Tutti i cambiamenti all’UI sono sensibili e coerenti
- Eventuali attività di programmazione parallela sono eseguite in modo sicuro.
- Il codice non è più complesso del necessario
- Gli sviluppatori non hanno implementato funzionalità che, sebbene possano risultare utili in futuro, non sono attualmente necessarie.
- Il codice ha unit test appropriati
- I test sono ben progettati
I nomi delle variabili e delle funzioni sono chiari e descrittivi. - I commenti nel codice sono chiari, informativi e spiegano il ragionamento dietro le decisioni piuttosto che fornire solo la descrizione
- Il codice è documentato in modo appropriato (preferibilmente in g3doc)
- Il codice è conforme alle guide di stile
In generale, i reviewers dovrebbero sempre approvare una changelist una volta che è in uno stato in cui indubbiamente migliora la salute del codice del sistema su cui lavora, anche se non è perfetta. Chiaramente ci sono delle limitazioni: ad esempio, se una changelist aggiunge una funzionalità che il revisore non ritiene necessaria, allora può negarne l’approvazione, anche se il codice è ben sviluppato. Il punto chiave è che non esiste un codice perfetto, ma solo un codice migliore: una changelist che migliora la manutenzione, leggibilità e comprensione del sistema non dovrebbe essere ritardata per giorni perché “non è perfetta”
La revisione del codice non solo garantisce la qualità tecnica del prodotto, ma svolge anche una funzione formativa. Questo processo può essere un’occasione per l’apprendimento di nuove nozioni e principi di progettazione del software, facilitando l’interscambio di commenti educativi e la condivisione di conoscenze tra i membri del team.
In questo contesto è utile anche fare accenno ai principi della code review:
- I fatti tecnici e i dati hanno la priorità rispetto alle opinioni personali o alle preferenze soggettive
- Sullo stile, l’autorità è questa guida (link esterno)
- Gli aspetti di software design sono raramente solo una questione di stile o preferenza personale
- Eventuali conflitti tra sviluppatori e reviewer devono essere risolti: non è ammesso lasciare appesa una changelist perché non si riesce ad arrivare ad un accordo
Checklist e strumenti per la revisione del codice
Prima di avviare il processo di revisione, è necessario verificare di avere un ambiente di sviluppo funzionante e correttamente configurato. Gli elementi da controllare nel corso della revisione possono essere esaminati in un ordine basato sull’obiettivo finale della code review, senza una specifica sequenza cronologica.
Leggibilità del Codice
Un codice ben scritto è leggibile e comprensibile. Ha nomi significativi per le classi, le variabili e le funzioni, rispetta un’indentazione corretta ed è coerente nello stile di codifica. È inoltre commentato in modo adeguato e pertinente.
Strumenti come SonarQube e linters come Flake8 per Python, ESLint per JavaScript o RuboCop per Ruby possono essere impiegati per analizzare la qualità del codice, individuare bug potenziali e migliorare la leggibilità.
Funzionalità
Il codice deve risolvere correttamente il problema o soddisfare i requisiti richiesti, garantendo una logica di funzionamento corretta ed efficiente. Strumenti open source di test automatici come Jest per JavaScript, Pytest per Python o Cypress con Cucumber, possono aiutare a testare e verificare la correttezza delle funzionalità aggiunte e garantire che le modifiche non compromettano quelle esistenti.
Gestione degli Errori
In questa fase si revisionano i controlli sull’input utente e che gli errori vengano gestiti in modo appropriato. Si verifica anche che i log degli errori siano chiari e informativi. Strumenti open source come Sentry e Rollbar consentono il tracciamento degli errori nel codice e il monitoraggio delle applicazioni in tempo reale.
Test
La revisione del codice comprende anche il controllo dell’aggiunta di nuovi test e la verifica del corretto funzionamento dei test esistenti. Sarà inoltre necessario eseguire test di integrazione e test funzionali, se applicabili. Abbiamo accennato prima a due strumenti open source che possono aiutare developer e reviewer: Jest e Cypress+Cumber. Jest è un framework di testing per JavaScript che si concentra principalmente sulle applicazioni React, offrendo un’esperienza di testing semplice e completa. La sua configurazione predefinita e le funzionalità come lo snapshot testing lo rendono popolare per testare componenti React. Dall’altro lato, combinare Cypress e Cucumber, consente di scrivere test in linguaggio Gherkin con Cucumber e utilizzarli per orchestrare e guidare i test reali attraverso Cypress. Questa sinergia consente una migliore comprensione dei requisiti dell’applicazione e fornisce un’automazione solida e comprensibile per verificare che l’applicazione funzioni correttamente in base a tali requisiti.
> Leggi anche: Test Automation: strumenti open source e vantaggi
Sicurezza
Ultimo, ma sicuramente non per importanza, il revisore deve assicurare lo stato di sicurezza del codice. Deve controllare prima di tutto che non siano presenti vulnerabilità conosciute e si deve assicurare che non ci siano problemi di sicurezza noti come injection, XSS, CSRF, etc. Inoltre, la revisione del codice è il momento giusto per eseguire un controllo specifico di autorizzazioni e autenticazioni.
Si possono utilizzare strumenti open source come OWASP Dependency-Check per controllare le dipendenze e rilevare vulnerabilità e strumenti di analisi statica come FindBugs per Java o Brakeman per Ruby per individuare potenziali problemi di sicurezza nel codice sorgente.
> Leggi anche: DevSecOps: principi e strumenti per la sicurezza integrata
Durante tutto il processo di revisione del codice è in ogni caso consigliato sfruttare piattaforme come GitHub o Bitbucket per commentare direttamente sul codice e tenere traccia delle modifiche richieste.
L’utilizzo di strumenti di integrazione continua come Jenkins o Ansible può agevolare nell’esecuzione automatica dei test e nell’identificare errori o problemi non rilevati localmente, prima della distribuzione del codice in produzione.
La revisione del codice è uno step fondamentale del ciclo di sviluppo del software e contribuisce a garantire la qualità, la sicurezza e l’efficienza del prodotto finale. Attraverso una checklist dettagliata e l’impiego di strumenti avanzati, è possibile analizzare ogni aspetto critico del codice, dalla leggibilità alla funzionalità, gestione degli errori e sicurezza. In altre parole, la revisione accurata del codice garantisce un prodotto finale robusto e di qualità, pronto ad affrontare le sfide del mercato.
Scarica la checklist
Controllando gli elementi qui sopra durante la code review, è possibile ridurre al minimo l’errore.
Tuttavia, non sono sufficienti: scarica la nostra checklist per scoprire tutti i controlli da eseguire durante la revisione del codice e migliorare la qualità della codebase.
