Coding Standard

Premessa:

le convenzioni su come scrivere codice sono importanti sia per gli sviluppatori, sia per il team, sia per il progetto, per molte ragioni:

• buona parte del codice scritto (indicativamente dal 70% al 90%) nella durata della “vita” del software dovrà essere mantenuto
• è molto difficile che il software sia mantenuto per la sua intera vita da chi ha scritto la sua prima versione
• le convenzioni aumentano la leggibilità del software, questo permette sia la risoluzione dei bugs più immediata, sia un aumento della velocità di comprensione della funzionalità
• vuoi sviluppare un prodotto di qualità

A seguire una code convention per il linguaggio Java.

 

Strutturazione del codice

Un nuovo package Java deve essere creato per ciascun gruppo di funzionalità correlate, inoltre le directories devono essere create come la convenzione dei nomi dei packages in java.

Sarebbe auspicabile che si crei un file con nome-del-package.txt oppure .html nel quale venga riassunto brevemente lo scopo del package e le classi, metodi funzionalità più importanti.

Anche se Java consente di avere più classi nello stesso file, è consigliabile avere la seguente corrispondenza: un file, una classe, ovvero ciascuna classe deve essere in un file separato, a meno che non si è sicuri che quella classe non pubblica venga utilizzata solo per quella esigenza specifica in quel file da un’altra classe.

Scrivere in tutti i files:

• il tag ‘$Id$’
• una lista della storia del file che comprende:
  • la data
  • l’autore
  • le modifiche effettuate
• se un file ha più di una classe scrivi un commento che indica il nome di tutte le classi presenti nel file e il loro scopo
• dopo il commento scrivi il package, lascia una riga vuota e scrivi gli import

a seguire un esempio:

/**
* Copyright (C) 2014, Nome dell'azienda 
*
* $Id: MyExample.java ,v 1.1 2014/02/01 10:01 autore Exp $
* Data Autore Modifiche
* Gen 30 2014 autore Creato
* Gen 21 2014 autore Aggiunta di due nuovi metodi
*/

package demo;

import java.util.Random;

 

Per le classi e le interfacce scrivere i commenti come da convenzione:

/**
 * Questa parte è il commento
 * 
 */

Prima della classe dovrebbe esserci sempre un commento della classe stessa che descriva lo scopo ed eventualmente anche un esempio di utilizzo.

Utilizzare anche i seguenti tags:

/**
* ...
* @author
* @version
* @see nomedellaclasse#nomedelmetodo
*/

Ecco un esempio di un commento di una classe e il suo utilizzo:

/**
* Questa classe rappresenta un dipendente
* Un esempio di utilizzo: 
* <pre> 
* Dipendente dipendente = new Dipendente();
* dipendente.getSkills();
* </pre> 
* 
* @author Nome Cognome oppure <a href="mailto:nomecognome@azienda.it"> </a> 
* @version $Revision: 3.1 $ $Date: 2014/01/30 10:28:29 $
* @see Lavoratore
*
*/
class Dipendente extends Lavoratore
{...
}

 

E’ consigliabile mantenere il seguente ordine di scrittura nelle classi:

• variabili della classe (public, protected, a livello di package, private)
• costruttori pubblici
• costruttori privati
• metodi pubblici
• metodi protected
• metodi con visibilità defaul
• metodi privati
• inner class

 

a seguire una tabella riassuntiva per i modificatori di accesso java quale tipo di visibilità hanno:

Modificatore	Class	Package	Subclass	World
public	Si	Si	Si	Si
protected	Si	Si	Si	No
nessun modificatore	Si	Si	No	No
private	Si	No	No	No

 

 

Per la variabili della classe seguire il seguente ordine:

• public
• protected
• nessun modificatore
• private

la convenzione javadoc consente di descrivere lo scopo, l’utilizzo delle variabili di istanza e delle variabili static. Consente anche l’utilizzo dei tags HTML.

@see URL
@see stringa

// Rappresenta il prezzo dell'item 
public double price;

Per i metodi la convenzione javadoc prevede la descrizione dello scopo, delle precondizioni, degli effetti, degli algoritmi, di come si utilizzano i metodi. Anche per i metodi è consentito l’utilizzo dei tags HTML.

 

@param nomeDelParametro descrizione del parametro
@return descrizione del valore di ritorno
@throws nomeDellaEccezione descrizione di quando si verifica l'eccezione
@see stringa
@see nomeDellaClasse#nomeDelMetodo

Per i commenti multilinea usare

/* commento con più linee
*/

Per i commenti di una sola linea usare

// commento di una sola linea

 

Ricorda il “perchè” e il “che cosa”.

Spesso i commenti descrivono ad esempio che cosa fa un metodo ma é bene descrivere nel commento dove opportuno, anche il perchè è stato fatto, è stato sviluppato quel metodo o quella classe.

Se l’algoritmo è complesso è bene descrivere l’algoritmo nel commento.

Layout

Il layout prevede l’indentazione, la lunghezza massima di ogni linea di codice e l’utilizzo delle parentesi graffe.

Per l’indentazione non utilizzare il tab ma 4 spazi per l’indentazione (oppure configurare l’IDE affinchè il tab abbia 4 spazi).

Impostare nell’ IDE la lunghezza massima di caratteri pari a 75 caratteri, questo consente una migliore leggibilità del codice. Questo dovrebbe valere anche per i commenti.

Per l’utilizzo delle parentesi graffe, solitamente si hanno una delle due seguenti convenzioni. Utilizzare la parentesi graffa di apertura nella linea dove viene definita la classe o il metodo oppure utilizzare la parentesi graffa di apertura all’inizio della linea successiva della definizione della classe o del metodo. Se si adotta quest’ultima convenzione le parentesi graffe saranno verticalmente allineate.

class MyClass
{
    ...
    public double getSales() 
    {
	if (condizione)
        {
           ...
        } else
        {
           ...
        }	
    }    
    ...
}

lasciare una linea bianca tra i vari metodi (incrementa la leggibilità).

Dichiarare le variabili dei metodi all’inizio del metodo, ad eccezione per i cicli.

Spazi bianchi.

Utilizzare uno spazio bianco nei seguenti casi.

Dopo una parola chiave di Java lasciare uno spazio bianco, ad esempio:

while (condizione)
{
...
}

Non utilizzare uno spazio bianco tra il nome del metodo e l’apertura delle parentisi. Questo consente una immediata identificazione del metodo.

Inserire lo spazio bianco dopo la virgola dei paramteri del metodo.

 public double getSales(int a, int b, String c) 
 {
     ...	
 }

Tutti gli operatori (ad eccezione del “.”) devono essere separati da uno spazio bianco:

int y -= x + z;
y = (g + j) / (u - o + d);

Dopo che si effetua un cast, si lascia uno spazio bianco.

 public double getSales((Object) c) 
 {
     ...	
 }

 Mantenere la leggibilità di eventuali linee di codice lunghe.

Nel caso di linee di codice lunghe e poco leggibili, è un bene, con il fine di aumentarne la leggibilità, spezzare la linea in due o più linee. Ad esempio dopo la virgola puoi andare a capo, oppure dopo un operatore. Considera infine che spezzare il codice in più linee è meglio farlo con le parti di codice che abbiano un livello di parentesi più “alto”.

Inoltre, una volta scritto il codice su più linee, allinea le linee stesse affinchè siano “allineate”, ovvero affinchè le linee  inizino verticalmente nello stesso punto.

Ovvero, questo codice è preferibile

 
keyboard = keyboardTypeA * (keyboardTypeB + keyboardTypeC - keyboardTypeD)
         + (keyboardTypeU + keyboardTypeI - keyboardTypeL);

a questo codice:

 
keyboard = keyboardTypeA * (keyboardTypeB + keyboardTypeC
         - keyboardTypeD) + (keyboardTypeU + keyboardTypeI - keyboardTypeL;

 

 Convenzione dei nomi.

Per i packages:

• adottare la convenzione java per il dominio (ad esempio i packages devono iniziare con it.nomeazienda. ecc.)
• devono essere lowercase

Per le classi:

• devono avere la prima lettera maiuscola
• la classe pubblica di ciascun file deve corrispondere al nome del file

Per le costanti:

• tutti i caratteri delle costanti devono essere maiuscoli
• le parole delle costanti sono unite tramite underscore

 

public final int UNA_COSTANTE = 10;

Se sono private o protected scriverle con un underscore iniziale poi l’uppercase per il carattere iniziale di ogni parola.

private int _unaVariabile = 3;

Per le variabili locali scrivere il primo carattere lowercase ma le altre parole con il primo carattere maiuscolo

private int unAltraVariabile = 5;

Per i metodi scrivere il primo carattere lowercase ma le altre parole con il primo carattere maiuscolo

public double getSomeFruit() 
{
   ...	
}

Utilizza il new o il create per i metodi del design pattern factory.

Utilizza il to (ad esempio il toNomeOggetto) per i metodi che converto in un oggetto.

Utizza il get e il set per quei metodi che danno o settano un oggetto

AnObject getAnObject(){...}
void setAnObject(AnObject){...}

 Consigli.

Scrivere un main in una classe separata che utilizza la tua classe applicativa, quindi non mettere il main nella classe applicativa. Il nome della classe del main dovrebbe essere il nome della classe che si luove utilizzare con il postfisso Main, ad esempio MyClass la classe da utilizzare, e MyClassMain la classe che contiene il main.

Scrivere uno Unit test che utilizza la tua classe applicativa.

Nei tests devono esserci esempi di utilizzo delle classi, oltre che a testare le funzionalità, sarebbe auspicabile che ci siano degli esempi di utilizzo.

Non scrivere codice hard coding.

Scrivi degli esempi di utilizzo di classi, preferibilmente nelle classi di tests.

Razionalizza e semplifica.

Se nel design si pensa ad una astrazione della classe allora definire una interfaccia, scrivere invece una classe astratta quando un metodo può essere utilizzato da tutte le sottoclassi.

Le interfacce sono più flessibili delle classi, poichè le classi non supportano l’ereditarietà multipla.

Utilizza i Generics per il tuo codice, ti consente di avere codice più robusto e con meno bugs.

Come gestire le eccezioni.

Quando scrivi il blocco del catch scrivi anche un log con un messaggio oppure stampa lo stack trace.

Scrivere un messaggio significativo dell’evento, non utilizzare generiche espressioni.

Sii dettagliato nel log, ad esempio scrivendo l’id dell’item che va in eccezione, affichè si possa capire successivamente il caso d’uso.

try
{
   ...
} catch(Exception e) 
{
	e.printStackTrace();
}

 

try
{
    ...
} catch (TransactionException te) 
{
    logger.log(te.printStackTrace());
}

A seguire un buon esempio di gestione delle eccezioni.

try
{
   f = new File(path);
} catch (IOexception ioE) 
{
    String m = ClassLoader.message(FILE_NOT_FOUND, path)
    throw new FileException(ie, m);
} catch (CustomException cE) 
{
    logger.log(cE.getMessage());
}

La gestione delle eccezioni devono essere in tutti i metodi in cui c’è la possibilità in cui una eccezione si possa verificare.

Variabili.

Non dichiarare le variabili public se non le dichiari final static.

Questo perchè nell’ Object Oriented Programming il dichiarare una variabile publica “modifica” il modello ad oggetti, in questo caso sposta il potere decisionale al di fuori dell’oggetto, al di fuori della classe.

Inizializza sempre le variabili.

Scrivi minor static possibili, ad eccezione del caso in cui si necessiti di costanti static. Questo perchè le variabili static non sono OO (Object Oriented).

Inoltre si creano anche metodi più dipendenti dal contesto e con eventuali effetti collaterali, con la possibilità di avere problemi sulla sincronizzazione.

Utilizza final per le variabili il cui valore non deve mai essere cambiato.

Quando scrivi le variabili di istanza e metodi considera il principio della minima visibilità, ovvero variabili e metodi devono essere meno esposti possibili alle altre classi e package.

Per le variabili di istanza che necessitano di essere scritte al di fuori della classe utilizzare un metodo con il set iniziale, ad esempio setNomeVariabile.

Non scrivere lo stesso nome di variabile  per una superclasse e una sottoclasse, questo è un errore.

Dichiara una nuova variabile locale invece di utilizzarne un’altra che è stata concepita con un altro scopo.

Dichiarare una variabile locale non all’inizio del metodo solo per  i cicli.

Assegna null a qualsiasi array, lista, collezione di oggetti che per un lungo tempo non viene utilizzata (Ref. Garbage Collection).

Metodi.

Se possibile non scrivere troppi metodi in successione:

object.methodA().methodB().methodC().methodD();

poichè sia si potrebbe avere uno stato dell’oggetto che non è quello voluto, sia potrebbero esserci problemi di sincronizzazione.

Commenta le classi e i metodi thread safe, è molto utile capirne lo stato e la logica.

Sincronizza metodi piuttosto che blocchi, utilizza syncronized sui metodi piuttosto che nei blocchi, questo consente di aver un incapsulamento migliore.

Se fai l’override di hashcode allora fai anche l’override di equals.

Se fai l’override di equals allora fai anche l’override di hashcode.

 

A seguire i principali vantaggi del Coding Standard:

• Ottimo quando si amministra e si automatizza il processo di build
• Quando si ha integrazione di codice si ha un codice “collettivo” con lo stesso standard
• Il codice è più facile da mantenere
• Permette una miglior lettura del codice agli altri ma non solo a loro
• Si ha lo stesso formato del codice sorgente e dei commenti, questo consente anche una miglior comprensione da parte di tutti gli sviluppatori del team
• Facilita la comunicazione

 

 

Alessandro Ceseno

PS: se hai domande scrivimi pure per mezzo della sezione contatti.

 

Continuos Integration

Una pratica Agile che uso è la pratica del “Continuos Integration”, della integrazione continua. Le interazioni tra le persone avvengono abitualmente, ogni giorno e abitualmente ogni giorno il software cambia, perchè i requisiti cambiano, la tecnologia cambia, il design cambia, il business cambia, le persone del team cambiano, molte cose cambiano e componenti software vengono integrati.

Quando accade questo per mezzo della pratica agile di “Continuos Integration“, ciascuna integrazione del sistema, ciascuna integrazione del codice è verificata per mezzo di un processo di compilazione automatico, una build automatica che deve comprendere anche la verifica dei tests. Questo tipo di approccio consente di aver molti meno problemi nel momento in cui si rilascia in produzione.

Come è indicato nel nome Continuos Integration, l’integrazione non è una fase con limiti temporati definiti ma l’integrazione è continua nel senso che accompagna lo sviluppo del software, questo si realizza mediante questa pratica agile.

Essendo continua, nel caso di errori, nel caso di bugs si può facilmente e velocemente regredire a uno stato precedente funzionante.

Questa pratica agile si effettua per mezzo del controllo del repository del codice sorgente.

Continuos Integration è una delle pratiche che fanno parte dell’ eXtreme Programming.

Per realizzare Continuos Integration è necessario avere un Server dedicato all’integrazione (Continuos Integration Server).

I tools che attualmente utilizzo per Continuos Integration sono Jenkis o Hudson.

Implementazione del software e CI (Continuos Integration).

Lo sviluppatore ha una copia del codice sorgente sulla sua macchina (pc o laptop).

Tale “copia” del codice sorgente la si è ottenuta per mezzo di un Source Code Management System. Attualmente utilizzo Git, in passato ho utilizzato Subversion.

(A seguire una breve descrizione di come questi due diversi sistemi di versionamento funzionano.

Per avere sulla macchina locale il codice del progetto già esistente lo sviluppatore nel caso di Git avrà fatto un “clone”, nel caso di Subversion lo sviluppatore avrà fatto un “check out”. Per mandare le modifiche del proprio codice al server, lo sviluppatore nel caso di Git effettuerà un push (preceduto da un commit locale), lo sviluppatore nel caso di Subversion effettuerà un commit.

Un Source Code Management System ha il compito di gestire il codice sorgente in un repository su un Server. Il codice sorgente sul Server è principalmente in una directory chiamata mainline. Il codice sorgente sulla macchina locale è in una directory chiamata Working Directory, ovvero nella working directory si ha una Working Copy del codice sorgente.

Lo sviluppatore lavora sulla sua macchina in locale per sviluppare una nuova feature, o per modificarne una esistente, ecc.

Questa pratica agile ha come caratteristica il fatto che il codice sviluppato abbia dei tests automatici.

Io sviluppo in TDD, in Test Driven Development. Effettuata l’implementazione della feature/s effettuo la build sulla mia macchina locale, la build effettua operazioni di compilazione, di creazione di altre/nuove librerie software ed esegue i test automatici.

Effettuata la build e verificato che in locale i test automatici funzionano, allora si è a buon punto nel processo che consertirà il “commit” del codice sul Server (comando commit con Subversion, comando pull con Git).

Ora si aggiorna la propria copia in locale (comando Update in Subversion, comando pull in Git): questa fase consiste nell’aggiornare il codice in locale con il codice del Server (del repository), questo consente una nuova build nella macchina locale e una nuova esecuzione dei tests e se i tests sono senza errori allora si può effettuare un commit del codice sul server.

Nel caso invece di errori nella build o nei tests allora lo sviluppatore dovrà prima di committare il codice sul repository del Server effettuare un fix dei problemi e/o tests.

In Continuos Integrator vi è una macchina di integrazione, un Server di integrazione.

Questa macchina di integrazione deve avere accesso al repository del codice (assumiamo che sia la mainline del codice).

La macchina di integrazione effettua una nuova build, questa build viene eseguita con il codice sorgente del repository. Se questa build non ha errori ed è corretta (anche i tests devono essere senza errori ovviamente) allora solo in questo caso si può affermare che l’implementazione della feature è stata effettuata.

Questa build effettuata dalla macchina di integrazione è normalmente effettuata da un software, io utilizzo Jenkins oppure Hudson.

Può verificarsi il fatto che due o più sviluppatori effettuano un commit del codice sul server di versionamento quasi contemporaneamente, in questo caso il server di continuos integration avvertirà nel caso di errori della build o tests e quindi i problemi che potrebbero sorgere possono essere risolti velocemente e avere di nuovo una build funzionante.

Controlla i tempi:

il server di integrazione non dovrebbe avere una build non funzionante per più di 24/48 ore.

 

E’ stato descritto a un più alto livello possibile il concetto di Continuos Integration.

Continuos Integration viene attuato per mezzo anche delle seguenti pratiche.

Avere un solo repository del codice sorgente

(ovviamente l’Operation deve effettuare backups).

Si scrive il codice sorgente per effettuare la build del software. Il codice sorgente del team viene gestito con software che possono avere diversi nomi, ma che gestiscono fondamentalmente il codice sorgente, i nomi più comuni sono: Source Code Management Tool, Configuration management, version control system, revision control system, source control.

Il software di gestione del codice sorgente consente al team, e quindi al progetto la corretta gestione dei seguenti casi d’uso/eventi:

• overwriting del codice: diversi sviluppatori possono lavorare in contemporanea sul progetto e non si ha overwriting di codice se non effettuato con consapevolezza.

• history del source code: è possibile accedere alla storia del codice sorgente e visionare e quindi poi eventualmente modificare la storia dei files

• scrivere le note di release del codice

• avvertire quando il codice sorgente stesso è stato modificato

E’ buona norma prima dell’inizio del progetto accertarsi che tutti i componenti del team sappiano utilizzare il software di versionamento del codice (attualmente Git e Subversion sono i migliori).

E’ buona norma versionare tutto il progetto, quindi codice sorgente, files di properties, eventuali scripts come i database scripts, eventuali librerie aggiuntive, ecc. e non versionare il compilato, questo perchè ogni persona del team dovrebbe essere un grado di effettuare su una nuova macchina il check out del codice, ovvero prendere il codice sel server di versionamento e metterlo in una nuova macchina ed effettuare una corretta (e completa) build, quindi nel server di versionamento deve esserci tutto ciò che è necessario.

I sistemi di versionamento consentono anche di creare branches del codice, il consiglio è quello di crearli solo se è veramente necessario.

Automatizza la build

Automatizza tutto quello che può essere automatizzato. La build può effettuare diverse operazioni, come la compilazione dei sorgenti, la CRUD di directory,ecc. tutte queste operazioni sono automatizzabili e quindi si devono automatizzare, poichè è possibile commettere errori in procedure non automatizzate.

Qualsiasi persona del team come scritto precedentemente dovrebbe essere in grado di prendere il codice sorgente del server di versionamento e per mezzo di un solo comando effettuare una corretta build.

Spesso una build completa richiede tempo ma spesso si utilizza un process building che è in grado di controllare la data del sorgente e quindi se con la nuova build il sorgente deve essere di nuovo compilato oppure no, questo consente un notevole risparmio di tempo nel processo di build. Inoltre il file di build dovrebbe consentire diversi target a seconda delle necessità.

Lo sviluppo viene effettuato per mezzo di un IDE (Integrated Development Environment, Eclipse è il mio preferito per Java ad esempio), molto spesso la build effettuata per mezzo di un IDE non consente la visibilità su problemi che potrebbero esserci in una build fatta bene da console (ad esempio perchè alcuni files sono nel classpath dell’IDE e non nel classpath dello script di build,ecc.).

Quindi è molto importante avere sempre una build funzionante che è eseguibile dal Server.

Includi i tests nella tua build

La build può effettuare diverse operazioni, tipicamente compilazione di sorgenti, creazione di librerie, spostamento e creazioni di directories, ecc.

Può esserci una build senza errori, ma un approccio agile prevede che ci siano i tests unitari, ovvero nello script di build devono esserci i tests di unità e devono essere dalla build stessa eseguiti e non dare errori.

Se si è sviluppato in TDD (Test Driven Development) si hanno test di unità più efficienti ed efficaci poichè si sono stati scritti prima del codice applicativo.

In ogni caso anche se non si è sviluppato in TDD si dovrebbero avere dei tests automatici e sarebbe ideale che tutti i tests fossero eseguibili con un unico comando.

 

I commits devono essere consistenti e frequenti: piccole funzionalità implementate in modo incrementale.

L’integrazione consente anche agli altri membri del team una consapevolezza delle funzionalità implementate. E’ importante che i commits effettuati nel repository oltre che aver un corretto design, che abbiano una build e i tests funzionanti.

Di seguito il corretto flusso che gli sviluppatori dovrebbero seguire finito di implementare una funzionalità e prima dell’effettivo commit del codice:

• chiedersi se si ha una build nell’IDE funzionante

• chiedersi se si ha una master build da console funzionante

• i test unitari si eseguono senza errori?

• effettua un update del codice dal server

• risolvi eventuali conflitti con la mainline

• riesegui la build

• verifica che la build sia funzionante

• verifica che tutti i tests siano senza errori

• commit del codice scrivendo un commeto identificativo della funzionalità implementata

I commits frequenti consentono anche nel caso di problemi o bugs una veloce soluzione.

Una buon approccio è effettuare il commit solo se si è implementata una funzionalità o una sotto funzionalità correttamente e consistente.

Inoltre frequenti commit aiutano gli sviluppatori a sviluppare semplici funzionalità. La Semplicity è una della caratteristiche dell’ eXtreme Programming (XP).

Questo consente anche una maggior sicurezza e conoscenza del software che si sta sviluppando.

 

Ciascun commit nel repository dovrebbe essere seguito da una nuova build sulla macchina di integrazione (Continuos Integration Server).

Come abbiamo detto precedentemente lo sviluppo è fatto su macchine locali, i commits sul repository su un’altra macchina (che abbiamo definito Server per comodità) sul quale c’è il repository (la mainlaine del codice). Ecco che la macchina di integrazione deve effettuare un checkout del codice dopo ogni singolo commit ed effettuare una nuova build e quindi verificare che la build sia corretta (ovviamente anche i test devono essere corretti). Avere una build funzionante di ambienti diversi consente di aver un maggior controllo e consapevolezza del codice.

E’ importante essere consapevoli che solo se la build della macchina di test viene creata senza errori allora solo in quel caso la funzionalità è da considerarsi implementata.

La build sul Server di integrazione può essere in due modi e uno è preferibile all’altro.

Un modo è che uno sviluppatore si colleghi in remoto sul server di integrazione ed effettuti il check out del progetto ed effettui la build manualmente.

Un altro modo che è quello consigliabile è utilizzare un software come Jenkis per l’integrazione, ovvero dopo ogni commit effettuerà un check out del progetto ed effettuerà una nuova build, e a seconda di come è stato configurato il software, il Server di integrazione avvertirà via email dello stato nella nuova build (se ha avuto successo oppure no). Alcuni preferisco configurarlo a seconda dell’opposto dell’ Hollywood principle. L’ Hollywood principle dice: “don’t call us, we’ll call you”, ovvero non chiamarci, ti chiameremo noi. Portato al concetto informatico di Continuos Integration, l’opposto consiste nel fatto che se la build non ha successo si avvertono gli utenti, o meglio, in questo caso gli utenti di un software di CI (ad esempio Jenkis) sono gli sviluppatori, si avvertono gli sviluppatori per mezzo di una email (ovviamente lo fa in automatico il software di integrazione, una volta configurato).

Alcuni configurano il server di integrazione per una sola build al giorno e magari notturna, anche se è meglio avere una integrazione continua che non averla, in realtà è meglio configurare una nuova build, quindi una nuova integrazione ogni volta che il codice della mainline è cambiato, questo è effettuare Continuos Integration.

Mantieni veloce la build.

Spesso si possono creare situazioni per la quale la master build necessità di tempo e qundi non è più una build veloce. Il consiglio è avere una build veloce. Questo consente agli svilluppatori stessi di non annoiarsi mentre eseguono la build e inoltre non si devo rifocalizzarsi sul codice, cosa che deve avvenire in caso di build lunga.

La master build non dovrebbe mai essere più lunga di 10 minuti, naturalmente è auspicabile che sia al massimo di due o tre minuti.

Nel caso di build lunghe e di commit frequenti e ravvicinati si potrebbero avere dei problemi, è importante conoscere bene anche il software di Continuos Integration.

Avere un ambiente di Test/Collaudo/Preproduzione (può essere chiamato in diversi modi) il più simile, meglio ancora se è il clone dell’ambiente di produzione.

In questo ambiente si dovrebbe avere qualsiasi tipo di problema che si ha nell’ambiente di produzione. Se i tuoi test hanno un diverso risultato in ambienti diversi allora non sono test scritti bene, i tests dovrebbero avere lo stesso risultato in ambienti diversi.

Si vede aver cura che sia la versione del database, sia la versione del sistema operativo sia la stessa dell’ ambiente di produzione, stesse librerie e stessa versione delle librerie software utilizzate e stesso hardware.

Per mezzo della virtualizzazione è abbastanza semplice effettuare cloni degli ambienti.

Semplicity.

Cerca di essere e mantenere il processo più semplice possibile.

Spesso le pensone sono focalizzate su cosa non funziona invece che su cosa funziona, lo sviluppo agile consente rapidi cambiamenti e questo vuol dire anche la possibilità di effettuare rapidi bug fixing.

Qualsiasi componente del team dovrebbe essere in grado di prendere l’ultima build ed eseguire l’applicazione, gli scopi possono essere molteplici.

La comunicazione è importante.

La comunicazione ha un ruolo importante in CI (Continuos Integration), quindi ogni componente del team dovrebbe essere in grado di visionare i cambiamenti effettuati sui server ed essere in grado di effettuare eventuali configurazioni.

Inoltre i software di Continuos Integration mettono a disposizione pagine web per mezzo delle quali può vedere mantenere monitorato lo stato delle varie build e dei vari logs, l’accesso allo stato delle build e dei logs è messo a disposizione ad ogni membro del team. Questo consente anche al team di aver maggior visibilità e conoscenza sulla build e sullo stato del software.

Il deployment deve essere automatizzato.

Continuos Integration prevede il trasferimento di files in macchine diverse, quindi si deve automatizzare questo processo e inoltre è importante che si abbia uno script di deploy che consenta a chiunque del team di effettuare il deploy in modo semplice, l’ideale sarebbe con un solo comando. Di conseguenza anche in produzione il rilascio può essere effettuato in modo semplice con un solo comando.

Il deployment automatico in CI consente in produzione una velocità di rilascio e una significativa riduzione di possibili errori.

Poichè l’ambiente di Test/Collaudo/Preproduzione dovrebbe essere il clone dell’ambiente si produzione, allora anche il rilascio in produzione dovrebbe essere simile a quello dell’ambiente di Test/Collaudo/Preproduzione.

Il processo di build automatizzato ed intervalli regolari permette di verificare se i cambiamenti di codice fanno fallire test che prima erano funzionanti, se i test hanno successo si “tagga” la versione del codice.

 

Conclusione: I vantaggi di CI (Continuos Integration)

Continuos Integration ha diversi vantaggi di:

• ridurre gli errori

• ridurre i rischi

• permette una maggior confidenza e conoscenza del software a tutti i membri del team

• i bugs sono molto più velocemente identificabili e risolvibili.
• i bugs sono anche cumulativi, questo significa che più bugs si hanno e più e difficile risolvere quel bug specifico, poichè quel bug è dato dalla sommatoria di altri bugs ein questo caso anche gli sviluppatori psicologicamente sono meno disposti a risolvere quel bug che è dovuto ad altri bugs. CI consente di ridurre i bugs in modo significativo

• si hanno deployment frequenti, con tutti i relativi benefici

• si amministra e si automatizza il processo di build

• si integra il lavoro del singolo nel lavoro del team

• si hanno feedbacks sui cambiamenti di codice, ma anche report, documenti

• si diminuiscono considerevolmente i problemi di integrazione

 

Alessandro Ceseno

PS: se hai domande scrivimi pure per mezzo della sezione contatti.