“La revisione del codice (code review) è il controllo sistematico (spesso conosciuto come revisione paritaria) del codice sorgente. È pensata per trovare e correggere errori sfuggiti nella fase iniziale di sviluppo, migliorando la qualità complessiva del software e le capacità degli sviluppatori. Le revisioni vengono effettuate in varie forme come la pair programming, spiegazioni esaurienti ed informali e ispezioni formali.” (fonte: Wikipedia)
In sostanza: controllare il codice altrui aiuta a migliorarsi. Wikipedia elenca quattro canonici tipi di revisione del codice ma in questo post ci soffermeremo sui vantaggi individuali di tale pratica.
In ambito aziendale la verifica del codice altrui è una pratica bistrattata e si fa di tutto per saltare questa fase e dedicarsi a progetti che producono guadagno, dimenticando tutto il resto.
Se dal punto di vista produttivo ciò è corretto e sacrosanto non è detto che lo sia per forza di cose anche per il singolo individuo. Questa tecnica, infatti, la si può usare anche al di fuori dell’ufficio.
Rivedere il codice altrui (meglio se di più persone e quindi sufficientemente vario) è un ottimo modo per imparare da soli, cercando di trovare ed imitare quanto di meglio si trovi in circolazione. Certo, ci vuole un buono spirito critico nel determinare rapidamente a priori quali progetti meritino di essere visionati, ma col tempo si affina il proprio gusto e le proprie capacità analitiche.
Tanto per cominciare si può scegliere tra qualche progetto Open Source famoso, magari non troppo grosso come dimensioni – non partite col kernel Linux! – e iniziare a leggerne il codice, provare ad analizzarlo e a comprenderlo.
Non serve leggere migliaia di righe di codice in milioni di file: ne basta poco per volta. Anzi è cosa buona leggerne magari poco da più fonti diverse: più progetti si analizzano, più è facile fare comparazioni, apprendere il concetto di qualità e imparare a scrivere codice.
Sì, trovare ed analizzare il codice altrui e comprendere come è stato scritto è un modo molto efficiente di imparare a scrivere codice a propria volta.
Si imparano molte più cose leggendo codice reale che non quello pseudo-accademico presente sui libri di programmazione. Servono entrambi, ma in modo bilanciato: la teoria resta teoria se non la si concretizza debitamente.
Revisionando codice vi capiterà spesso di imbattervi in software che formalmente sembra ben scritto, ma sotto sotto è pietoso dal punto di vista algoritmico. Non parliamo solo della notazione O-grande ma anche alla scelta delle strutture dati più adatte al contesto, degli algoritmi più efficienti per svolgere un compito, eccetera.
Analogamente potreste trovarvi – e vi troverete, potete scommetterci! – ad avere a che fare con codice iperottimizzato ma incomprensibile da leggere, estendere e manutenere.
Non è necessario analizzare il codice col solo scopo di trovare errori ma lo si può analizzare quantitativamente e soprattutto qualitativamente.
Ad esempio, per qualunque codice sorgente analizzato è possibile porsi queste e molte altre domande
Come è scritto? è sufficientemente chiaro ed intuitivo?
Come sono usati i commenti? È tutto sufficientemente documentato?
Si capisce cosa fa concretamente quel progetto? E le sue parti?
Si capisce chiaramente dove parte? C’è l’equivalente di una funzione main()?
Come è strutturato? Moduli ben isolati ed indipendenti o spaghetti code selvaggio?
Contiene codice di test e/o si segue qualche metodologia di testing (unit, fuzz, …)?
Ha caratteristiche strane che balzano immediatamente agli occhi?
Segue delle coding conventions/standards precise? Chi le ha definite e perché? Vengono sempre rispettate?
Segue un qualche approccio di sviluppo moderno o si nota il peso degli anni, la sua lunga storia di sviluppo?
Quali parti meritano un encomio e quali di essere radicalmente riscritte e/o sottoposte ad un serio refactoring?
C’è modo di identificare e contattare eventualmente gli autori?
Complessivamente posso ricavare qualche utile best practice da replicare/imitare?
Qualche “bonus point” per i più smaliziati
Si riesce a riconoscere l’applicazione di qualche sana linea guida di sviluppo?
Come siamo messi a livello di ingegneria del software (software engineering)? Viene seguito qualche modello o metodologia di sviluppo?
Si potrebbe estendere in modo agevole? Da dove si dovrebbe partire?
Contiene errori vistosi che si possono correggere in prima persona?
Come siamo messi a livello di sicurezza del codice?
Contiene codice dichiarato deprecato e/o famoso per essere insicuro?
Contiene commenti stupidi? Usa nomi di variabili presi dai cartoni animati o comunque senza senso e inadeguati al contesto? Contiene commenti allarmanti sul genere “hic sunt leones”/”here be dragons”?
Ci sono commenti per produrre documentazione, ad esempio in stile Doxygen?
A chi mi rivolgo se ho dei problemi? Mailing list? Forum? Community online?
È gestito tramite un sistema di tracciamento delle revisioni/controllo di versione come Subversion o Git? È disponibile attraverso qualche sito-repository online come GitHub o Sourceforge? Viene gestito tramite la metodologia di integrazione continua? Dispone di un qualche sistemi di ticketing online per segnalare i problemi riscontrati e la loro risoluzione?
Ci sono sviluppatori o partecipanti della comunità che possano fungere da buoni modelli da seguire, imitare?
Si tratta di domande semplici.