Da diversi anni ormai sviluppo software in Java, in progetti piu' o meno vasti e complessi. Una delle mie principali preoccupazioni e' sempre stata la ricerca di una valida soluzione per l'organizzazione del lavoro. Come spesso capita quando si portano avanti piu' attivita' allo stesso tempo, infatti, si ha la percezione che la confusione generata dal passaggio da un impegno all'altro possa rallentare la produttivita', o rendere comunque difficile il perseguimento degli obiettivi di progetto.

Inizialmente, diversi anni fa, la mia principale preoccupazione era mantenere il codice in un posto sicuro, il classico backup. Questo problema l'ho nel tempo risolto con soluzioni differenti: copia su usb-pen a fine giornata, invio del codice come allegato email su GMail, file server remoto con storage in raid, ecc. Oggi adopero una soluzione un po' piu' elegante e comoda, che sfrutta un servizio di directory remota ed un software di sincronizzazione di una cartella locale con lo spazio web in questione, il tutto offerto gratuitamente da www.dropbox.com.

Ben presto mi sono reso conto che la semplice copia dei file non era sufficiente, mentre sarebbe stato molto piu' utile avere una storia delle modifiche fatte sul codice, magari con la possibilita' di aggiungere commenti a tali modifiche. Il passaggio a Subversion fu un'illuminazione nel mio modo di gestire il codice. 

Al crescere dei progetti, della loro complessita', ma soprattuto del loro numero, mi sono reso pero' conto di quanto fosse importante avere un modo puntuale e comodo di gestire la documentazione collegata al progetto e che non era conveniente inserire come commenti al codice. Uno strumento di wiki in questi casi e' una soluzione valida: una prova l'ho fatta anche con Google Sites, che ben si integra con tutta l'infrastruttura Google ed e' davvero comodo per inserire un po' di tutto (immagini, file, testo, ecc.) in un ambiente che offre gia' tutti i servizi di multiutenza, versioning, affidabilita'. Tuttavia, stiamo sempre parlando di una piattaforma non gestita direttamente da noi, che quindi potrebbe un giorno presentare delle limitazioni o non essere adatta ad usi particolari (anche se sono abbastanza fiducioso che con le API esposte da google per manipolarne i dati si possano fare cose molto interessanti). In sostituzione, credo che lo stesso Drupal, motore di questo sito, potrebbe, con i moduli giusti, essere un degno sostituto, e non nascondo infatti che nei prossimi giorni mi appresto a provare una installazione di Drupal come gestore della documentazione dei progetti, oltre che come document management system piu' in generale.

Una ulteriore necessita' nata dal lavoro contemporaneo su piu' progetti e' quella di tener traccia del lavoro da dover fare, dei problemi sorti e non risolti, dei bug individuati: in poche parole serve un sistema di issue tracking (e in giro ce ne sono non pochi). Nel tempo ho adoperato Mantis, l'infrastruttura di Google Code, Trac (che fa anche tante altre cose) e qualche altra soluzione nota. Per ognuna di queste soluzioni, ho sempre cercato di avere una integrazione dei ticket gestiti dal sistema, con l'ambiente di sviluppo che usavo (praticamente sempre Eclipse). Questa integrazione e' particolarmente semplice se si adopera Mylyn (incluso di default nelle attuali versioni di Eclipse).

L'organizzazione di un ambiente di lavoro efficiente non finisce qui pero'. Quando un progetto cresce diventa sempre piu' difficile riuscire a farne un build, ossia rispettarne tutte le dipendenze con librerie esterne o moduli software appartenenti ad altri progetti. Chiaramente esistono tool che supportano anche in questo: il piu' noto e' Ant, di cui a mio parere vanno almeno imparate le basi, anche se poi si decide di usare altro. Un altro tool leggermente piu' complesso, ma che fa anche molte cose, e' invece Maven, che ho cominciato ad usare da poco (ed infatti non lo adopero in "produzione"), e che sto lentamente apprendendo grazie anche ad alcune risorse, come questo libro: Better builds with maven.

Quando poi si e' fanatici della flessibilita', come sono io, si possono anche considerare tool per la virtualizzazione di tutto l'ambiente di sviluppo: VirtualBox permette di far girare in un sistema operativo host un numero indefinito di sistemi operativi guest del tutto indipendenti fra loro e dall'host. Installare in una macchina virtuale tutto l'ambiente di sviluppo permette quindi di replicare facilmente questa VM, per, ad esempio, fornirla ad un altro membro del team di sviluppo, o come faccio io, consente di portare con se un HD USB su cui e' conservato il file che rappresenta la VM e che puo' essere portato a spasso per eseguire quella stessa macchina in qualsiasi posto (a casa, sul portatile, a lavoro, ecc.)

Dopo questa velocissima carrellata sono costretto ad ammettere che non ho ancora trovato una sistemazione di tool e tecniche che mi soddisfi e, per quanto le cose siano migliorate nel tempo, continuo a cambiare qualcosina di mese in mese, con l'obiettivo di raggiungere una sistemazione ottimale. Il problema e' trovare il giusto equilibrio fra i vari tool e definire un modo semplice e comodo per integrare l'uno con l'altro. Se trovero' una soluzione, prometto di renderla nota!