Non rompere mai il codice versionato

Il versionamento dei codici sorgenti è probabilmente lo strumento più necessario per un team di sviluppo software, ma allo stesso tempo quello meno usato. Iniziamo con questo articolo a fornire alcuni suggerimenti sul versionamento del codice, prendendo subversion come strumento di riferimento e la mia attività professionale come base di analisi.

In una normale attività di sviluppo portata avanti da un team di persone, accade normalmente che ogni membro del team prende in carico la risoluzione di una attività, che fa avanzare lo stato generale del progetto. Quindi più attività lavorative concorrono a modificare contemporaneamente il codice sorgente.

Compito di chi gestisce il progetto è quello di assegnare i compiti in maniera tale che le attività concorrenti non vadano ad intralciarsi, l'una con l'altra. Questo però in genere non basta a rendere stagni i vari ambienti di lavoro; può infatti accadere che una modifica fatta da qualcuno possa interferire con le attività di qualcun altro.

Per questo la pratica consigliata è quella di effettuare con la frequenza più alta possibile il ciclo “code, test, update, test, commit”. Ovvero effettuare un insieme di modifiche, testarle, aggiornare la propria copia locale dei sorgenti con l'ultima versione presente nel sistema di versionamento, rilanciare i test, se non ci sono fallimenti aggiornare il codice versionato con le proprie modifiche.

Le due fasi di test sono importantissime perché aiutano a non mettere sotto configurazione un codice che non funziona o peggio non compila. Non è richiesto che al commit venga sottomesso il codice che risolva il compito assegnato; l'importante è che il codice non venga rotto, ovvero che continui a compilare e a fare le cose che faceva prima nella maniera attesa.

In alcuni casi reali ho anche sentito di piccoli espedienti che aiutano al rispetto di questa regola. Ad esempio, chi rompe il codice esegue ogni sera, prima di lasciare il lavoro, un check-out dell'intero progetto, lo compila e stila un report sui test automatici. Oppure, ogni volta che viene rotto il codice sorgente si paga un pegno di un euro, che finisce in un salvadanaio che finanzia una qualche attività di socializzazione extra lavorativa.

Per una consulenza sul versionamento dei progetti software contattami su poderico@gmail.com.