Modifiche in maniera esclusiva di file.

Ci troviamo sempre nell'ipotesi che un gruppo di sviluppo lavori in maniera concorrente su un insieme di sorgenti. La possibilità che più di una persona si trovi a lavorare sullo stesso file non è trascurabile. Anzi, nella pratica di tutti i giorni è un evento che capita spesso.

Cosa fare in questi casi di modifiche concorrenti allo stesso file? Alcuni sistemi di versionamento forniscono la possibilità di inibire modifiche ad un file che è sottoposto a modifiche. Questa è una politica molto conservativa che, a mio avviso, limita in maniera eccessiva i gradi di libertà di un team di sviluppo.

Può accadere che una o più persone rimangano ferme con le proprie attività, fino alla fine delle attività di chi ha bloccato per primo un file. O peggio creare un vero e proprio dead-lock: un primo programmatore ha bloccato il file1 mentre il secondo programmatore ha bloccato il file2; poi ad un certo punto il primo programmatore ha bisogno di modificare il file2, però il secondo programmatore prima di rilasciare il file2 ha bisogno di modificare il file 1.

Ma è poi così pericoloso modificare contemporaneamente lo stesso file? La pratica di tutti i giorni dice che assolutamente i problemi sono minimi. Infatti per prima cosa c'è l'esperienza e bravura del capo progetto ad assegnare i task in maniera tale da rendere minimi le sovrapposizioni. Nel caso poi di modifiche allo stesso file e molto raro che le modifiche riguardino la stessa funzione o porzione di codice. Questi sono i casi risolti agevolmente da uno strumento di fusione o merge del codice sorgente.

Meno frequentemente capita che due modifiche coinvolgano la stessa porzione di codice, in questo caso una decisione umana è necessaria. Nella maggior parte di questi casi entrambe le modifiche vanno bene, va solo scelto l'ordine esatto. Ancora una volta gli strumenti di merge ci aiutano semplificandoci le operazioni di fusione.

Quando capita che più modifiche alla stessa porzione di codice risultano non compatibili, vuol dire che qualche cosa nel processo di gestione non ha funzionato. Questo è l'unico e vero caso dove l'intervento umano è fondamentale per dirimere il conflitto.

In conclusione il consiglio finale è di favorire e controllare le modifiche concorrenti allo stesso file, in modo da rendere agile le attività di sviluppo.

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