Progettazione del software

Memento mori

2011-04-04T22:33:00.000+02:00

Il "memento mori" è un modo per ricordare a tutti i membri del team le varie scadenza. Per mia abitudine, mi piace concordare le scadenze, per cui non sarebbe necessario ricordarle. Ma ho visto che, poi in pratica, è meglio ricordare a tutti le scadenze di tutti.

Il "memento mori", una volta stampato, appare molto simile ad un foglio con dei post-it appiccicati sopra. I post-it verdi indicano i vari flussi di sviluppo; i post-it gialli riportano il nome della risorse coinvolta, scadenza e una breve descrizione dei risultati attesi.

Attività in corso

2011-02-13T23:01:00.000+01:00

Con questo foglio del nostro Cruscotto di progetto siamo in grado di tenere sotto controllo le attività in corso e assegnate ai vari membri del gruppo di sviluppo.
Le informazioni da inserire sono organizzate per colonne, alcune in input ed altre calcolate con delle formule del foglio elettronico. Vediamo i dettagli

title - questa colonna ospita il nome della persona in carico dell'attività
start - qui inseriamo la data di inizio dell'attività
end - è una colonna calcolata e rappresenta la data di fine dell'attività, calcolata sommando alla data in start i giorni lavorativi della colonna effort e i giorni di ritardo della colonna delay.
description - contiene una descrizione sintetica dell'attività.
estend - è la data stimata di fine dell'attività, senza prendere in considerazione l'eventuale ritardo.
effort - è il numero di giorni lavorativi stimati per il completamento dell'attività.
delay - è lo scostamento della previsione iniziale dell'effort dalla reale durata dell'attività. In quanto scostamento, può essere un numero sia positivo che negativo.
ellapsed - è il numero di giorni solari che intercorrono dall'inizio dell'attività alla sua fine.

Alcune note importanti su questo foglio:

i dati qui presenti sono usati direttamente come input per i gant visualizzati nella pagina iniziale del cruscotto è nella pagina Timeline. I campi title, start, end e description hanno questi nomi, anche se non proprio chiarissimi, perché i componenti grafici che disegnano i gant fanno assunzione sulla presenza di colonne così denominate.
per inserire una nuova riga ovvero una nuova attività da tracciare, conviene copiare una riga già esistente.
le milestone sono delle attività senza la colonna end.
la milestone oggi ha lo scopo di identificare in un solo colpo d'occhio quali attività devono ancora iniziare e quali potrebbero essere già finite.
per ordinare le attività rispetto alla data di inizio, ad esempio quando si inseriscono delle nuove attività o quando si vuole aggiornare la posizione della milestone oggi, basta semplicemente ordinare la colonna B del foglio elettronico.
l'attributo delay va aggiornato giornalmente, in base a variazione di stime o ritardi effettivamente misurati.

Quando una attività viene completata, verificato che il campo delay sia opportunamente compilato, va spostata nel foglio Attività terminate. Ci sono alcuni casi in cui una attività programmata debba essere sospesa per poi essere ripresa in un secondo momento; in questo caso l'attività in questione va spostata nel foglio Attività sospese. L'ultimo caso preso in considerazione è quello di una attività annullata perché non più utile per il progetto; in questo caso l'attività in questione va spostata nel foglio Attività annullate.
Questa classificazione delle attività non più in corso è molto importante per effettuare delle statistiche sul progetto, ad esempio per misurare la velocità di sviluppo o l'accuratezza delle stime fatte.
Per esperienza, questo è il foglio di lavoro giornaliero durante l'attività di coordinamento di un progetto di sviluppo.

Punti Aperti

2011-01-31T22:50:00.000+01:00

La pagina dei Punti aperti è abbastanza semplice e ci aiuta a tener traccia dei punti aperti e della loro risoluzione. Le colonne presenti sono:

Punto aperto - descrive brevemente il punto aperto.
Risoluzione - deve dare in maniera chiara la risoluzione del punto aperto, per poi considerarlo risolto.
Data apertura - indica la data in cui il punto è stato aperto
Data chiusura - indica in che data il punto è stato risolto e quindi considerato chiuso.

Attenzione ad inserire le date di apertura e chiusura, in quanto a partire da questi dati si aggiorna il bilancio dei punti aperti, rappresentato dal grafico a barre della pagina Cruscotto.

Lo stato del progetto in un colpo d'occhio

2010-10-17T22:53:00.000+02:00

La prima pagina del Cruscotto fornisce una visione di insieme sullo stato del progetto. Troviamo 4 sezioni distinte:

Bilancio dei punti aperti - Un diagramma con due barre verticali indica il bilancio dei punti aperti e dei punti chiusi. Per punto aperto si intende una questione che impatta, prima o poi, l'andamento del progetto e che necessità di una azione. Per punto chiuso si intende un punti aperto risolto.
Attività in corso - Un piccolo gant illustra le attività in corso e quelle prossime. Nella figura è possibile notare due attività, rispettivamente assegnate a Tony e Mary; la data odierna che aiuta a riconoscere le attività in corso; le due mile-stone M1 e M2.
Ritardo - I tre quadranti indicano, in termini percentuali, il ritardo accumulato dall'inizio del progetto e relativo alle attività terminate; il ritardo in corso relativo alle attività in corso, ovvero iniziate e non ancora terminate; il ritardo totale dato dalla somma del ritardo accumulato e da quello in corso.
Statistiche - Una breve sezione riguardante l'effort medio stimato, il ritardo medio e l'effort medio effettivo, espresso in giorni/uomo.

Tutte le informazioni necessarie per compilare questo primo foglio del nostro cruscotto, vengono tutte dedotte dagli altri fogli:

Punti aperti
Attività in corso
Attività terminate
Attività sospese

Completano il cruscotto altri fogli di supporto:

Memento mori
Timeline
Attività annullate

Cruscotto di progetto

2010-05-07T10:41:00.002+02:00

Dopo un po' di tempo rieccomi su questo blog.
Vi voglio presentare quello che ho chiamato cruscotto di progetto.

Lo trovate come template su google docs, questo perché lo scopo principale del cruscotto è di coordinare le attività di sviluppo di un team. Quindi avere la possibilità di condividere in maniera distribuita le informazioni sulle attività in corso e quelle a breve scadenza.

L'ho messo a punto mentre lo usavo per un progetto di sviluppo, composto da due filoni principali: uno di modifiche adattative e un altro di evolutive. La composizione del team è variata durante il progetto, da un minimo di 3 ad un massimo di 6 persone. Tutto questo per dire che è il risultato di una esigenza ed applicazione reale.

Proviamo a scoprirlo un po' alla volta, anche con l'aiuto vostro. Soprattutto le critiche.

Controlla il tuo lavoro prima di ogni commit

2008-06-17T18:57:00.000+02:00

Può sembrare una banalità, ma controllare cosa viene messo in configurazione è molto importante perché 1. evita di rompere la continuità della repository e 2. è un ottimo punto di auto revisione del proprio lavoro.

Come sistema di versionamento uso SVN e come interfaccia grafica TortoiseSVN, che ha una funzionalità molto utile proprio per la verifica del proprio lavoro. Nella versione inglese si chiama check for modification.

Tramite questo comando riesco a vedere in maniera chiara e semplice il diff tra la mia area di lavoro e la base area, ovvero il contenuto dell'ultima update. Riesco anche a vedere, in maniera analoga, il diff tra la mia area di lavoro e l'ultima revisione presente sul sistema di configurazione.

Come già detto, con il primo diff analizzo le mie ultime modifiche, riuscendo anche a parcellizzarle in modo da fare commit con commenti diversi a partire dallo stesso set di modifiche. La seconda diff permette invece di andare a capire cosa accadrà se faccio una update, in particolare di scoprire se ci saranno dei conflitti.

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

La metafora della mappa

2008-05-07T17:11:00.003+02:00

Leggendo OpenUp in a nutshell di Per Kroll, ho trovato una considerazione molto interessante su i processi:

A process is like a map: Use it to understand the big picture and as a reference, but when reality and the map don't match, trust reality.

ovvero:

Un processo è come una mappa: usala per capire il quadro d'insieme e come riferimento, ma quando la realtà e la mappa non coincidono, allo credi alla realtà.

Cosa ci insegna questa metafora? Che quando si adotta un processo di sviluppo, questo va saputo adottare ed adattare. Che le descrizioni dei processi sono, per quanto precisi e dettagliati, non adatti o ideali per ogni applicazione o ogni situazione.

L'intelligenza e il buon senso devono sempre prevalere.

I dodici passi per un codice migliore

2008-04-01T17:16:00.000+02:00

Seguo da molto tempo e con molto interesse il blog di Joel Spolsky. Ecco un articolo molto interessante su i criteri da seguire per scrivere del codice migliore. Sono espressi sotto forma di test, in modo da fotografare in pochi secondi la situazione di un team di sviluppo.

Usi un sistema di versionamento del codice sorgente?
Puoi fare un build in un solo passo?
Effettui dei build giornalieri?
Hai un database dei bug?
Sistemi i bug prima di scrivere del nuovo codice?
Hai sempre una schedulazione aggiornata?
Hai delle specifiche?
I programmatori hanno un ambiente di lavoro tranquillo?
Usi il migliore strumento che è possibile acquistare?
Hai dei tester?
I candidati scrivono del codice durante il loro colloquio di lavoro?
Effettui dei test di usabilità?

A quante risposte rispondente con un si? Se sono meno di 11 c'è qualcosa di consistente da migliorare nel processo di sviluppo.

Aggiungi un commento all'articolo con il numero di si, così possiamo costruire una fotografia della qualità del software sviluppato in Italia.

Per una consulenza sul processo di sviluppo di progetti software contattami su poderico@gmail.com.

Usa una working directory solo quando serve

2008-03-30T15:25:00.002+02:00

Come faccio a lavorare su un progetto sotto versionamento? In quanti modi è possibile farlo? Finora abbiamo visto come è possibile creare una working directory, avendo in mente il nostro obiettivo di modificare il codice per poi pubblicare.

Ci possono essere altre situazioni dove io voglio poter lavorare sulla copia dei sorgenti di un dato progetto senza però avere la necessità di pubblicare le mie modifiche. Ad esempio perché non è il motivo per cui ho bisogno dei codici sorgenti.

Ad esempio posso essere un tester o un responsabile della qualità, per cui mi basta avere una copia pulita dell'ultima revisione. Oppure mi posso occupare di delivery, per cui anche in questo caso mi basta una copia pulita di un certo tag.

Per tutti questi casi è utile e sufficiente fare, usando la terminologia subversion, l'export piuttosto che un check-out. Infatti in questo modo evitiamo di copiare anche tutti i file di controllo che altrimenti sarebbero creati che, per quantificare, raddoppiano la dimensione dello spazio occupato. In questo modo evitiamo pure che, con altri sistemi di versionamento diversi da subversion, il server tenga traccia dell'operazione di check-out che non vedranno mai nessuna commit.

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

Il valore di una working directory

2008-03-27T23:23:00.002+01:00

Abbiamo appena fatto il check-out del progetto su cui dobbiamo lavorare in una directory: la nostra working directory. Da questo momento in poi inizia il nostro ciclo “modifica, fondi, pubblica” e con esso cambia il valore del contenuto della working directory.

Siamo sul “modifica”, quindi stiamo aggiungendo o modificando del codice. Arriviamo alla fine della nostra modifica. Cosa succede se per sbaglio cancellassimo tutta la nostra directory? Perderemmo tutto il lavoro fatto, ovvero la mia working directory ha un valore, che economicamente è pari almeno alla controparte economica del lavoro fatto.

Purtroppo non sono ancora nelle condizioni di poter fare una commit. Infatti ho una certa confidenza che il mio lavoro sia corretto con lo stato della repository al momento dell'ultimo update; quello che devo fare è fare un update e verificare se le mie ultime modifiche sono ancora compatibili con le modifiche fatte dagli altri miei colleghi.

Ed è esattamente quello che devo fare. Faccio quindi il mio bel update, lancio i miei test, faccio dei piccoli aggiustamenti che a questo punto mi rendono confidente sul fatto che ora le mie modifiche sono compatibili con l'ultima revisione disponibili. Cosa è successo al valore della mia working directory? Questo è chiaramente aumentato, però ora posso finalmente pubblicare le mie modifiche con una commit.

Stimare il valore di una working directory con l'equivalente economico del lavoro speso per apportare le modifiche è una semplice stima per difetto. Questa stima è tanto più precisa tanto più è alta la frequenza del ciclo “modifica, fondi, pubblica”. Infatti quante più modifiche funzionanti sono presenti solo in una working directory e tanto più alto è il suo valore, che sempre più si scosta dalla semplice equivalenza economica del lavoro speso. Possiamo arrivare fino al paradosso che una working directory assume un valore pari al valore dell'intero progetto.

I consigli che si possono dare sono quindi due:

organizzare il lavoro in maniera da avere delle commit frequenti e, ovviamente, corrette;
dotarsi di un sistema di backup che provveda automaticamente alla salvaguardia delle working directory.

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

Lo strumento principale per sviluppare software

2008-03-17T17:37:00.004+01:00

Qual'è lo strumento principale per sviluppare software? Intendo proprio quello che senza non si fa alcun software di qualità.
Pensiamoci un po'... ci sono i compilatori, gli IDE, i libri e manuali. Il c++, java e python? Linux anzi no windows, anzi no il mac.

Davanti a tutti, però, ce ne sta uno senza il quale non riusciamo a fare niente di buono: il nostro cervello. Se il nostro cervello funziona bene, allora anche il software che produciamo funziona bene.

Chiaramente il sillogismo si applica a tutti i campi della nostra vita, ma a noi interessa il processo di sviluppo del software. E nello specifico, come si mette in relazione il software prodotto e la nostra mente.

Possiamo dire che se quello che stiamo scrivendo, il software che ci è stato commissionato, non funziona bene è perché la nostra mente, il nostro cervello, non ha dato il massimo di se? Anzi, senza scomodare il massimo, non ha dato quanto bastava?

Secondo Andy Hunt il problema è proprio biologico. Io aggiungo quello che deriva dalla mia esperienza.

La pace e la calma mentale è il miglior posto dove scrivere software. Quali sono gli agenti che agitano la quiete interiore? Vedo almeno due grosse spinte: le distrazioni e i problemi extra lavorativi.
Le distrazioni sono peggiori quando auto generate dalla nostra mente. Ad esempio l'uso compulsivo di chat, web e posta elettronica: verificare ogni 5 minuti se è arrivata posta anche se abbiamo impostato un alert che ci avvisa; ricaricare la pagina di repubblica.it che non si sa mai cascasse il mondo; 15 chat aperte contemporaneamente che vuol dire una interruzione ogni 5 minuti. Il consiglio che do in questi casi è di cercare di educare se stessi e chi ci sta vicino ad un uso più ragionato di questi strumenti.
Per i problemi extra-lavorativi, che sono molto delicati, il consiglio che posso dare è proprio di sfruttare l'opportuinità lavorativa per ritagliarsi quel breve intervallo di tempo dove si riesce ad estraniarsi dalla realtà.

Una volta riconosciuto il punto debole nel nostro processo creativo, dobbiamo essere abbastanza maturi da cercare anche le soluzioni. Prima regola è quella di trasformare ogni fallimento in un'occasione per imparare dai propri errori e migliorarsi continuamente. Questo implica uno studio e ricerca continui: tecniche, linguaggi, metodologie. Ma anche leggere un buon libro di cucina, o di storia o di sociologia, perché dalle affinità c'è sempre occasione per imparare.

Nel processo di riconoscimento e auto miglioramento, che a questo punto possiamo quasi chiamarlo di correzione dell'errore che c'è nella nostra mente, cerchiamo sempre di farci aiutare da un mentore. Se ne abbiamo uno come vicino di scrivania, ovviamente.

Documentazione e revisione del codice

2008-03-10T10:40:00.003+01:00

Il consiglio di non scrivere la documentazione del codice dopo aver scritto il codice è, in generale, un buon consiglio. Quello che accade però in pratica è che viene puntualmente disatteso.

Come rimediare allora?

Ad esempio introducendo nel processo di sviluppo una fase di revisione del codice, accompagnata dalla scrittura della documentazione. Ancora meglio se questa documentazione finisce nei commenti al codice sorgente, come si fa con doxygen e compagni.

La revisione e scrittura della documentazione può essere fatta profiquamente anche dall'autore del codice sorgente. E garantisco che il numero di errori o di potenziali problemi scoperti non è trascurabile.

Agile Software Development

2008-03-05T10:42:00.003+01:00

Alcuni principi che sento di consigliare sono quelli indicati dal manifesto per lo sviluppo agile del software, meglio conosciuto come Agile Software Development.

Il valore dato ad alcuni elementi del proceso di sviluppo vengono cambiati. Valgono di più le persone e l'interazione tra di loro che i processi e gli strumenti; vale di più un software funzionante che una documentazione esauriente; vale di più la collaborazione con il cliente che la contrattazione di un contratto; vale di più saper rispondere ai cambiamenti che seguire un piano.

Quali sono i principi dietro il Manifesto Agile?

La nostra priorità più alta è di soddisfare il cliente attraverso il rilascio continuo e frequente di software da provare.
I cambiamenti dei requisiti sono i benvenuti, anche se durante lo sviluppo avanzato. Un processo agile gestisce i cambiamenti a favore della competitività del cliente.
Rilasciare frequentemente del software funzionante, da un paio di settimane ad un paio di mesi, preferendo interavalli più piccoli possibili.
Commerciali e sviluppatori devono lavorare insieme giorno per giorno al progetto.
Costruire i progetti intorno a persone motivate. Dargli l'ambiente e il supporto necessario e confida nel fatto che un buon lavoro verrà fatto.
Il modo più efficace ed efficiente di trasmettere informazioni a e dentro un gruppo di sviluppo e una conversazione faccia a faccia.
Avere del software funzionante è la prima misura del progredire del progetto.
I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero mantenere uno stato costante di pace indefinitamente.
Un'attenzione continua verso l'eccellenza tecnica e alla buona progettazione migliorano l'agilità.
Semplicità -- l'arte di massimizzare la quantità di lavoro non fatto -- è essenziale.
Le migliori architetture, requisiti e progetti emergono da gruppi auto-organizzati.
Ad intervalli regolari, il gruppo riflettere su come diventare più efficace, regolando ed aggiustando l'ambiente circostante di conseguenza.

Stampateli su un foglio ed affiggeteli!

Cancellare in maniera definitiva dal sistema di versionamento con molta parsimonia

2008-02-08T15:06:00.001+01:00

I sistemi di versionamento devono essere visti come dei buchi neri, come dei pozzi, dai quali non è permesso cancellare niente. Se un file o una directory è entrata a far parte di una revisione di un software, allora non deve essere più possibile cancellarlo; pena la perdità del requisito di base di ogni sistema di versionamento: essere in grado di riprodurre in qualunque momento una data revisione di un software.

Per questo motivo molti sistemi di versionamento non presentano affatto un comando per cancellare definitivamente un file o directory; altri invece la presentano come un comando riservato al solo amministratore del sistema.

Può infatti accadere che per errore contenuti non pertinenti col il software che si sta sviuppando vengano introdotti nel sistema di versionamento. Magari può pure capitare che questi file siano anche molto pesanti in termini di occupazione dello spazio disco. In questi casi è ragionevole pensare che l'amministratore possa in maniera sicura rimuovere definitivamente questi contenuti.

Quindi la regola di base è di usare la possibilità di cancellare in maniera definitiva con molta attenzione. Distinguere i casi in cui un file non avrebbe mai dovuto entrarne a far parte o semplicemente un file che non deve far parte parte più delle nuove revisioni.

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

Usare repository diverse per cose che sono veramente scorrelate

2008-01-30T10:00:00.000+01:00

Quanti repository diversi usare all'interno della nostra azienda? Diciamo che la piccola o media impresa di sviluppo software lavora completamente con un unico repository.

Ad esempio, in una piccola impresa di sviluppo, un unica istanza di subversion è sufficiente per 1. supportare le attività degli sviluppatori; 2. mantenere le versioni ufficiali pronte per il rilascio; 3. coordinare il lavoro degli sviluppatori fuori sede.

Chiaramente sono attività tutte correlate e quindi trovano normale coesistenza in un unico sistema di versionamento.

Provvederei a fare repository diverse se, ad esempio, fornissi servizi di hosting. Quindi ogni cliente avrebbe la propria istanza del sistema di versionamento.

Personalmente non ho mai vissuto la necessità di repository diverse, ma ho sentito di organizzazioni molto complesse che usano più repository per riflettere il loro processo di sviluppo, separando fisicamente i vari flussi di sviluppo.

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

Mettere sotto configurazione quello che serve strettamente

2008-01-28T15:27:00.000+01:00

Di un progetto software, cosa mettere sotto configurazione? Non esiste una regola generale, come sempre bisogna usare un po' di logica nelle cose che si fanno. E' però possibile dare delle linee guida.

Sicuramente di un progetto c/c++, non dovrebbero essere messi sotto configurazione tutti i file intermedi; analogamente anche i file temporanei generati dall'ambiente di sviluppo. Generalmente, anche gli eseguibili e librerie generate non dovrebbero essere messe sotto configurazione. Tutto questo evita che il repository cresca più del necessario rispetto alle finalità di sviluppo e si evitano finti conflitti.

Quindi la regola generale è di mettere sotto configurazione solo quello che è strettamente necessario.

Personalmente rompo questa regola quando metto sotto configurazione librerie o eseguibili di terze parti, che quindi hanno una particolare versione e che non sono soggetti a modifiche o attività di sviluppo. In questo caso, l'utilizzo che se ne vuole fare è quello di essere usati da un altro progetto; ad esempio, di una libreria si vorranno usare i “.h” e le librerie già compilate, evitando possibilmente l'onere di ricompilazione.

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

Provare lo sviluppo concorrente come meccanismo per massimizzare le potenzialità di un gruppo di sviluppo.

2008-01-24T21:30:00.000+01:00

Molti responsabili di progetto ritengono che avere due o più persone che lavorano sugli stessi insiemi di file sorgenti è una cosa molto pericolosa e, in generale, da evitare.

Sicuramente questo è vero quando non viene usato nessuno strumento di configurazione. Accade in questi casi che la separazione del lavoro è molto netta: Tizio lavora su certi file; Caio su altri file diversi da quelli di Tizio; Mamozio su file diversi ancora e così via. I file sorgenti sono duplicati su file system diversi; ogni sviluppatore modifica i propri senza avere una diretta visione di quello che stanno facendo gli altri, in questo modo si rinvia senza un motivo giustificato il momento in cui eventuali problemi verranno al pettine. Da ultimo non togliamo l'operazione noiosa quanto pericolosa, di fondere i vari sorgenti a mano.

Tutti i problemi appena evidenziati sono risolti agevolmente da un sistema di configurazione. Questo permette di liberare le potenzialità represse, sfruttando a pieno i vantaggi dello sviluppo concorrente.

Facciamo l'esempio banale di due sviluppatori: uno che scrive il codice e l'altro che scrive il codice di test. Quello che normalmente accade è che il secondo scopre gli errori che il primo ha scritto. In molti casi il secondo sarebbe anche in grado di risolverli in maniera automatica. Senza l'uso di un sistema di configurazione il secondo non potrebbe fare altro che segnalare al primo gli errori trovati e aspettare che vengano risolti; viceversa viene data la possibilità al secondo di lavorare in maniera molto autonoma, obbligandolo a rivolgersi al primo solo in casi di vera necessità.

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

Mantenere la propria copia locale il più possibile allineata con il repository.

2008-01-23T11:02:00.001+01:00

Quando più sviluppatori lavorano in maniera concorrente sullo stesso progetto, mantenere un alto grado di aderenza della propria copia locale con l'ultima versione è una cosa molto importante.

Questo garantisce che le modifiche e i test che stiamo scrivendo, sono compatibili con le modifiche e i test che gli altri. Nulla vieta, infatti, che possa accadere che uno sviluppatore riesca a lavorare senza mai fare un update. Né sarebbe giusto prevedere un meccanismo automatico di update, perché questo potrebbe rallentare e interferire con la normale e naturale attività di programmazione.

Il mio consiglio è quello di agire su due fronti. Il primo è quello di abituare i membri del team di sviluppo di comunicare agli altri membri le modifiche inserite sotto configurazione; questo porta ad una naturale verifica e condivisione di quello che si sta facendo.

Il secondo è quello di abituarsi a fare update ogni volta sia possibile, ad esempio farlo sempre prima di una commit.

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

Dottrina del “modifica, fondi e pubblica”.

2008-01-14T11:12:00.000+01:00

Usando sistemi di versionamento tipo subversion il ciclo di operazione svolte assume la forma del “modifica, fondi e pubblica”.

Effettua le tue modifiche al codice sorgente; fondile con le modifiche che nel frattempo sono state pubblicate; se il codice sorgente non è rotto pubblica le nuove modifiche.

A me piace aggiungere due fasi di test: una tra il modifica e fondi e l'altra tra il fondi e pubblica. I test che devono essere rigorosamente automatici devono avere lo scopo di verificare l'aderenza del codice ai requisiti da realizzare.

Il primo test ha lo scopo di verificare che le modifiche che sono state scritte sono corrette. Almeno in maniera ragionevole. Il secondo test ha lo scopo di verificare se le modifiche fatte da altri non hanno rotto o modificato la semantica di quello che abbiamo scritto.

Mi piace rimarcare il concetto che i test devono essere automatici: i test manuali non sono adeguati allo scopo. Appena possibile analizzeremo le problematiche dei test automatici.

Oltre al ciclo è anche importante saperne calibrare la frequenza. Deve essere adeguatamente stretto in modo da pubblicare e importare quasi in tempo reale le modifiche scritte da se stesso e dagli altri. Non troppo stretto per non perdere troppo tempo nell'importare e verificare le modifiche degli altri; né troppo largo in modo da non scrivere modiche per un codice troppo cambiato. Nella mia esperienza da 3 a 5 cicli al giorno sono un buon compromesso, ma come sempre dipende dall'ambiente e dal progetto.

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

Raggruppare logicamente i file coinvolti in una operazione di check-in

2008-01-05T16:51:00.000+01:00

A fine giornata può capitare che siano stati modificati più file, ed è normale. E' altrettanto normale che le modifiche effettuate non siano logicamente correlate. Ad esempio può capitare che, per implementare una nuova funzionalità, siano state apportate modifiche a strati o blocchi logici diversi. Per i ben noti principi di programmazione modulare, le diverse modifiche ai vari blocchi sono tra di loro indipendenti; se così non fosse c'è qualche serio problema di progettazione.
In questo caso è buona norma raggruppare i file in operazioni distinte di check-in, commentandole opportunamente. Nel fare queste operazioni fare attenzione a non rompere il codice versionando delle modifiche che dipendono da altre.
Questa accortezza permette di estrarre con facilità il più piccolo insieme di modifiche logicamente correlate. Operazione utile quando le modifiche riguardano codice condiviso da più progetti.

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

Commentare in maniera appropriata ogni check-in

2008-01-04T22:20:00.001+01:00

L'operazione di check-in applicata su un insieme di modifiche le rende pubbliche e disponibili agli altri membri del gruppo di sviluppo. Gli strumenti di versionamento permettono di verificare con estrema semplicità le modifiche effettuate; non è altrettanto semplice capire che effetto hanno o dovrebbero avere tali modifiche.
Per questo motivo è possibile associare al check-in un commento, che ha lo scopo di descrivere le modifiche inserite e l'effetto dichiarato che hanno rispetto all'intero progetto. Il commento deve essere chiaro, sintetico ma allo stesso tempo esauriente.
Una pratica molto utile è quella di inserire nel commento un riferimento ad un sistema esterno di gestione delle attività. Ad esempio, se inserisco nel sistema di gestione delle attività un difetto da risolvere, posso inserire nel commento l'ID associato al difetto. O magari direttamente l'indirizzo http alla descrizione e storia del difetto.
Sicuramente quello che sconsiglio è di effettuare dei check-in senza commenti. Fanno perdere molto tempo quando si guarda la storia delle modifiche di un file e fanno innervosire chi deve capire in poco tempo quando e come una certa funzionalità è stata modificata.
Probabilmente come nel caso di check-in che rompono il codice versionato, dei dissuasori sociali possono aiutare ad evitare l'assenza di commenti. Esiste pure la possibilità di vietare check-in senza commenti, me ritengo più utile che sia lo scrupolo e l'attenzione dei membri del gruppo a ricordare l'uso dei commenti.

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

Modifiche in maniera esclusiva di file.

2007-12-31T15:33:00.001+01:00

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.

Non rompere mai il codice versionato

2007-12-30T00:00:00.000+01:00

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.