Development

Migliorare la qualità del codice con SonarQube

Se sei uno sviluppatore, ecco come migliorare la revisione della qualità del codice con SonarQube.

February 15 2016

In un ambiente di sviluppo dinamico come quello di oggi, in cui più team lavorano sullo stesso codice e spesso vengono apportati cambiamenti, mantenere un certo livello di leggibilità e qualità del codice è fondamentale per raggiungere uno sviluppo di successo. Un simile ambiente richiede di seguire certe convenzioni a livello di codifica, in modo che il codice possa essere capito da chiunque sia coinvolto nel processo.

Per noi di Infobip, è fondamentale che i prodotti che consegniamo rispettino i più alti standard di qualità. Il codice sorgente è al centro di ogni prodotto, e la qualità del codice è così il fattore più importante per determinare la qualità del prodotto nel complesso.

Per mantenere un controllo di alta qualità, abbiamo scelto di implementare la revisione del codice nel nostro processo di sviluppo. Dopo qualche tempo, tuttavia, la revisione ha iniziato a richiedere troppo tempo, allontanandoci da altre importanti attività. La revisione del codice consisteva non solo in un processo di revisione creativa, ma anche nel controllo di errori ripetitivi, nell'utilizzo di norme di convenzione e così via. Abbiamo messo in discussione l'intero processo, e la soluzione più logica è stata l'automazione di alcune sue parti.

Nei nostri centri di sviluppo proviamo ad automatizzare il maggior numero possibile di attività manuali, così da poterci concentrare sull'innovazione. È proprio questa, infatti, che ci rende la scelta migliore per i nostri clienti. In questo momento i nostri sviluppatori possono distribuire automaticamente i servizi, scrivere API pubblici in modo facile e veloce e generare librerie client in più linguaggi di programmazione. Per trovare la soluzione perfetta che ci aiutasse ad automatizzare parte della revisione del codice, tuttavia, ci è voluto molto tempo. Dopo aver studiato vari strumenti, abbiamo capito che SonarQube soddisfa tutti i nostri requisiti.

Maggiori informazioni su SonarQube

SonarQubeè una piattaforma open source per l'analisi della qualità del codice. Insieme ad Understand, semmlee altri, fa parte della famiglia degli strumenti di analisi statica del codice.

La piattaforma riceve come input il codice sorgente, che può essere inviato da IDE o estratto da SCM. I plugin SonarQube, che rendono più semplice l'esecuzione dell'analisi del codice, sono disponibili per tutti gli IDE più popolari. In base all'input, la piattaforma inizia ad applicare delle regole predefinite e verifica che siano rispettate. Il risultato dell'analisi include poi diverse informazioni utili e propone dei miglioramenti.

Se abbiamo scelto SonarQube è grazie alle tante ed esaustive regole Java. Al momento esistono infatti più di 700 regole Java, e il numero continua a crescere. Le analisi che eseguiamo riguardano principalmente codice Java, ma possono essere facilmente eseguite su codice scritto in altri 20 linguaggi di programmazione.

In più, SonarQube è integrabile: se hai bisogno di supportare un certo linguaggio o vuoi scrivere le tue regole, ti consente di scrivere i tuoi plugin. Se hai bisogno di aggiungere al codice le tue regole, puoi farlo utilizzando le espressioni XPath o creando un nuovo plugin tramite Java.

La piattaforma SonarQube consiste di quattro componenti: strumenti di analisi, server, plugin installati sul server e infine, ma non ultimi per importanza, database.

Architettura SonarQube

Gli strumenti di analisi eseguono l'analisi del codice riga per riga. Forniscono informazioni sul debito tecnico, la copertura e la complessità del codice, i problemi individuati ecc. I problemi individuati nel codice possono essere bug, potenziali bug, fattori che potrebbero portare a errori in futuro e così via. Una volta completata l'analisi i risultati possono essere visualizzati sulla pagina web ospitata sul server web di SonarQube. Il server web semplifica la configurazione dell'istanza e l'installazione del plugin di SonarQube e offre un'intuitiva panoramica dei risultati.

Enigneering

Panoramica dei risultati

Alcuni codici possono ospitare diversi problemi. Le regole sono diverse, e in base alla loro gravità possono essere raggruppate in 5 diversi tipi: Blocker, Critical, Major, Minor e Info. Qualsiasi bug o potenziale bug presente verrà indicato come Blocker o Critical, mentre problemi secondari come "Impossibile utilizzare numeri magici" vengono indicati come Minor o Info.

Ecco qualche esempio delle regole violate più spesso:

Engineering

Regole violate più spesso

Il principale vantaggio di SonarQube è che tutti i dati vengono salvati in un database relazionale in cui qualsiasi sviluppatore si trova solitamente a proprio agio. Il database che abbiamo scelto è un database MySQL. Il principale motivo alla base di questa scelta è il nostro forte supporto per le tecnologie open source.Se preferisci altri database, o magari li conosci meglio, tra i database supportati trovi anche PostgreSQL, Oracle, e altri.

Configurare SonarQube

L'architettura di SonarQube consente di separare server e database e persino di creare repliche dei database e distribuire server su più macchine per migliorare le prestazioni e la scalabilità.

Ai fini del test, o se vuoi provare altre delle varie funzionalità di SonarQube, puoi analizzare uno o due progetti usando un server web con un database incorporato. Se l'ambiente viene configurato correttamente dall'inizio, non avrai problemi a far migrare il database e il server SonarQube da una macchina di sviluppo locale al server. Con i suoi contenitori, Docker può aiutarti a farlo: ti consente di raggruppare tutto ciò di cui hai bisogno (codice, runtime, librerie di sistema) e distribuirlo con facilità su qualsiasi macchina. Esiste inoltre un contenitore Docker ufficiale di SonarQube, dotato di una versione H2 incorporata, così non devi perdere tempo a creare il tuo. Se necessario per i lavori più importanti da eseguire con SonarQube, è anche possibile configurare un database esterno.

Noi abbiamo iniziato con una macchina virtuale dedicata, e non abbiamo avuto problemi finché il numero di progetti non ha superato un certo livello e non abbiamo iniziato ad analizzare codice ogni giorno. Tuttavia, abbiamo notato un drastico calo delle prestazioni e tempi di durata dell'analisi maggiori. A questo punto abbiamo iniziato a dividere su più macchine i diversi livelli SQ (architettura).

Come prima cosa abbiamo diviso il database e il server Sonar. Abbiamo accettato il consiglio di far rimanere SonarQube sulla stessa rete.  Per distribuire SonarQube abbiamo utilizzato un contenitore Docker, che ci avrebbe consentito di installarlo in modo semplice su un'altra macchina se avessimo avuto bisogno di prestazioni migliori.

SonarQube e l'Integrazione continua

Come dicevamo in precedenza, ci occupiamo in prima persona dell'automazione, e facciamo il possibile per dedicare il minor tempo possibile ai processi che possono essere automatizzati e sfruttarlo per la parte creativa del nostro lavoro. L'analisi del codice rientra perfettamente nella storia dell'integrazione continua.

Sosteniamo e mettiamo in pratica l'integrazione continua e lo sviluppo agile; ecco come appare per noi un processo di risoluzione di un'attività:

Si parte dallo sviluppatore (in questo caso sviluppatrice: la chiameremo Alisa) che si vede assegnare delle attività e deve iniziare a svolgerle. Nella fase di risoluzione dell'attività, Alisa esegue l'analisi del codice su IDE e ottiene i risultati, per poi ripetere il processo. Così sa se tutti i requisiti di qualità del codice sono soddisfatti, mentre la logica deve essere controllata da lei stessa. Quando è certa che il codice soddisfi tutti i requisiti, Alisa salva il nuovo codice nell'archivio e chiede a Bob di esaminarlo. Dopo aver salvato i cambiamenti nell'archivio GIT, l'hook web fa partire la build di Jenkins. La build viene eseguita automaticamente, e l'artefatto con la nuova funzione viene reso disponibile nell'archivio Maven interno e può essere distribuito in produzione in tutta facilità.

Bob esamina il codice scritto da Alisa ed esegue delle analisi per verificare che la qualità del codice sia del livello giusto. Dopo aver interpretato i risultati, a Bob rimane solamente la parte più creativa del lavoro: l'esame della logica del codice. Se tutto va come dovrebbe, l'attività è completa e la nuova funzione è pronta per la produzione.

Engineering

Gestione del codice sorgente con server CI e SonarQube

Nella versione 4.0 presentiamo la modalità di analisi incrementale. Questa modalità può essere utilizzata per controllare se i nuovi cambiamenti infrangono le regole importanti, e va eseguita dallo stesso sviluppatore che ha apportato questi cambiamenti. Prima della versione 4.0, uno sviluppatore avrebbe dovuto avviare l'analisi sull'intero progetto anche se i cambiamenti avessero riguardato solo due o tre file, mentre con la nuova funzione i tempi di analisi sono notevolmente inferiori. Oltre alla nuova modalità incrementale sono inoltre disponibili l'analisi dell'intero progetto, ovvero un'analisi riga per riga che invia i risultati al server e li archivia nel database, e una modalità di anteprima che esegue l'analisi completa, ma non archivia alcun risultato nel dabatase.

Al momento stiamo utilizzando la modalità di analisi dell'intero progetto con archiviazione dei risultati per le build analizzate durante la notte e la modalità anteprima dopo ogni salvataggio.

In questo modo possiamo monitorare il controllo qualità del codice da un salvataggio all'altro. Inoltre, resta a nostra disposizione la cronologia dei dati sulla qualità del codice, così possiamo osservare il comportamento della qualità per tutta la durata del progetto.

Conclusioni

L'utilizzo di SonarQube semplifica il controllo della qualità del codice e riduce il numero di bug reali e potenziali. Gli sviluppatori possono concentrarsi di più sulla logica e dedicare il loro tempo ai requisiti di analisi aziendale e alla ricerca di soluzioni ottimali per casi concreti. Inoltre, dopo l'implementazione i manager hanno iniziato a monitorare la metrica; in base ai risultati, infatti, hanno ritenuto che fosse possibile avere maggiori informazioni sullo sviluppo.

Concludo con una citazione da John F. Woods:

"Scrivi sempre il tuo codice come se sapessi che chi si occuperà della manutenzione è uno psicopatico violento che sa dove vivi"

Cosa aspetti? Oggi è il giorno giusto per analizzare il tuo codice!