CP pensareprogettareprogrammare n.

134 aprile 2004

Allestire un ambiente di sviluppo

di Stefano Fornari
Allestire un ambiente di lavoro completo per un team di sviluppo prevede la scelta di sistemi ` hardware e diversi software. Si possono tuttavia conseguire ottimi risultati a un costo piu che ragionevole

Stefano Fornari ` E CTO di Funambol, startup focalizzata nello sviluppo di middleware per il wireless data synchronization.

pubblicato su WWW.INFOMEDIA.IT stampa digitale da Lulu Enterprises Inc. stores.lulu.com/infomedia

Infomedia
` Infomedia e limpresa editoriale che da quasi venti anni ha raccolto la voce dei programmatori, dei sistemisti, dei professionisti, degli studenti, dei ricercatori e dei professori dinformatica italiani. Sono pi` di 800 gli autori che hanno realizzato per le teu state Computer Programming, Dev, Login, Visual Basic Journal e Java Journal, molte migliaia di articoli tecnici, presentazioni di prodotti, tecnologie, protocolli, strumenti di lavoro, tecniche di sviluppo e semplici trucchi e stratagemmi. Oltre 6 milioni di copie distribuite, trentamila pagine stampate, fanno di questa impresa la pi` grande ed u inuente realt` delleditoria specializzata nel campo della a programmazione e della sistemistica. In tutti questi anni le riviste Infomedia hanno vissuto della passione di quanti vedono nella programmazione non solo la propria professione ma unattivit` vitale e un vero a divertimento. ` Nel 2009, Infomedia e cambiata radicalmente adottando ` un nuovo modello aziendale ed editoriale e si e organizzata attorno ad una idea di Impresa Sociale di Comunit` , a partecipata da programmatori e sistemisti, separando le attivit` di gestione dellinformazione gestite da un board a comunitario professionale e quelle di produzione gesti` te da una impresa strumentale. Questo assetto e in linea con le migliori esperienze internazionali e rende Infomedia ancora di pi` parte della Comunit` nazionale degli u a sviluppatori di software. ` Infomedia e media-partner di manifestazioni ed eventi in ambito informatico, collabora con molti dei pi` imporu tanti editori informatici italiani come partner editoriale e fornitore di servizi di localizzazione in italiano di testi in lingua inglese.

Limpaginazione automatica di questa rivista e realizzata al ` 100% con strumenti Open Source usando OpenOffice, Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp, Python e BASH

For copyright information about the contents of Computer Programming, please see the section Copyright at the end of each article if exists, otherwise ask authors. Infomedia contents is 2004 Infomedia and released as Creative Commons 2.5 BY-NC-ND. Turing Club content is 2004 Turing Club released as Creative Commons 2.5 BY-ND. Le informazioni di copyright sul contenuto di Computer Programming sono riportate nella sezione Copyright alla ne di ciascun articolo o vanno richieste direttamente agli autori. Il contenuto Infomedia e 2004 Infome` dia e rilasciato con Licenza Creative Commons 2.5 BYNC-ND. Il contenuto Turing Club e 2004 Turing Club ` e rilasciato con Licenza Creative Commons 2.5 BY-ND. Si applicano tutte le norme di tutela dei marchi e dei segni distintivi. ` E in ogni caso ammessa la riproduzione parziale o totale dei testi e delle immagini per scopo didattico purch e vengano integralmente citati gli autori e la completa identicazione della testata. Manoscritti e foto originali, anche se non pubblicati, non si restituiscono. Contenuto pubblicitario inferiore al 45%. La biograa dellautore riportata nellarticolo e sul sito www.infomedia.it e di norma quella disponibi` le nella stampa dellarticolo o aggiornata a cura dellautore stesso. Per aggiornarla scrivere a info@infomedia.it o farlo in autonomia allindirizzo http://mags.programmers.net/moduli/biograa

FOCUS

Professione informatico

Allestire un ambiente di sviluppo

Allestire un ambiente di lavoro completo per un team di sviluppo prevede la scelta di sistemi hardware e diversi software. Si possono tuttavia conseguire ottimi risultati a un costo pi che ragionevole
di Stefano Fornari

ulla scia del motto anno nuovo vita nuova, allinizio dellanno ho iniziato una nuova attivit, naturalmente legata allo sviluppo software. Tra i mille problemi che ne conseguono, ho avuto il compito e il piacere di organizzare interamente ex-novo lambiente di sviluppo. Ho cos potuto mettere a frutto varie esperienze carpite qua e l durante lattivit di consulenza che ho prestato negli anni passati. Il compito pu non essere semplice, ma si possono ottenere buoni risultati con uno sforzo ragionevole. In questo articolo presenter lorganizzazione dellambiente di lavoro in termini di sistemi, software e procedure di sviluppo, senza per avere la presunzione di considerarlo un ambiente ottimale o di riferimento. Semplicemente, nel mio caso funziona, quindi credo possa funzionare anche in altre situazioni; oppure pu essere uno spunto per trovare soluzioni migliori.

DBMS Application server Project builder Backup

Osservazioni preliminari
Per inquadrare il tipo di esigenze e di ambiente di lavoro necessario, utile accennare al tipo di sviluppo software da noi realizzato. Lazienda della quale sono direttore tecnico si occupa dello sviluppo di un middleware Java per la sincronizzazione dati, il device management e lapplication provisioning. Fornisce inoltre supporto e consulenza per quanto riguarda le problematiche citate e il prodotto stesso. Un aspetto fondamentale della piattaforma lo sviluppo di un portale di sincronizzazione che permette a sviluppatori di applicazioni e contenuti di mettere a disposizione i loro prodotti, lasciando allinfrastruttura del portale tutti gli aspetti legati alla sincronizzazione dati. Sebbene il team di sviluppo sia al momento costituito da poche persone, nostra intenzione crescere molto rapidamente e quindi lambiente di sviluppo deve essere pensato e predisposto per la gestione di gruppi di lavoro pi numerosi. Nella mia esperienza ho trovato fondamentali diversi tool e software per lo sviluppo, di cui elenco i pi importanti: IDE ed editor Version control system Bug tracking system

La lista pu naturalmente essere allungata a piacere, ma i componenti elencati mi sembrano una buona dotazione almeno per iniziare. E devo dire che rivolgendosi al mercato, la suddetta dotazione pu esaurire tranquillamente buona parte del budget dedicato al reparto tecnico. Quanto abbiamo speso? 0 (zero) dollari, euro, lire o qualsiasi valuta vorrete considerare! Ebbene s, possibile organizzare un intero ambiente di sviluppo con soli software open source, senza spendere un centesimo e, nella mia esperienza, senza rinunciare ad affidabilit ed efficienza (anzi!). Dal punto di vista hardware, dove invece non c possibilit di non spendere nulla, ho ottenuto dal mio CEO tre server, di cui due dedicati allo sviluppo, mentre gli sviluppatori possono scegliere la piattaforma che preferiscono. Attualmente sviluppiamo su computer portatili e sistema operativo Windows XP. Nelle prossime sezioni verranno descritti pi accuratamente la configurazione di sistema, i singoli software e il processo di sviluppo adottati. Per ulteriori approfondimenti la rete una miniera inesauribile di risorse, quindi dove opportuno segnaler i link utili.

Architettura di sistema
Come gi accennato, lambiente di sviluppo, da un punto di vista hardware, costituito da una rete locale a cui sono stabilmente collegati i tre server e a cui si collegano i portatili quando arriviamo in ufficio. La scelta dei portatili come computer di sviluppo dettata da motivi di comodit e flessibilit. possibile lavorare da casa senza problemi e non necessario avere una postazione fissa in ufficio. Nellottica di avere un team di sviluppo numeroso, in cui non tutte le persone sono generalmente presenti in ufficio tutti i giorni, questo si traduce in una notevole ottimizzazione delle risorse fisiche dellufficio stesso (scrivanie, sedie, apparecchi di rete, ecc.). I server hanno compiti ben definiti: un file/web server, un server di sviluppo e un server di QA (quality assurance). Il file/web server il principale server di servizi, che fornisce tutte le funzionalit necessarie al buon funzionamento della rete locale, favorendo e ottimizzando la gestione delle risorse condivise. Funziona quindi da serbatoio di memoria di massa con i suoi due dischi da 120 Gb luno ed esegue servizi di database per le applicazioni, di web e mail server, DNS, ecc. 19

Stefano Fornari

sfornari@infomedia.it

CTO di Funambol, startup focalizzata nello sviluppo di middleware per il wireless data synchronization.

Computer Programming n. 134 - Aprile 2004

FOCUS
FIGURA 1
WinCVS

Il server di sviluppo invece dedicato allo sviluppo vero e proprio e in particolare ai build del prodotto. In un ambiente di sviluppo con pi sviluppatori, come vedremo nel seguito, i singoli programmatori lavorano generalmente in locale, su parti specifiche dellapplicazione. per necessario avere una macchina di riferimento, su cui ci sia sempre lultimo build e a cui tutti i membri del team possano accedere per verificare che le funzionalit sviluppate funzionino correttamente e siano integrate nel modo giusto nel build del giorno. Il server di sviluppo ospita anche software server e non, che non conveniente o possibile installare sulle singole postazioni di sviluppo, per esempio database o software di integrazione. Il server di QA dimensionato per ospitare un particolare build a scopo di test, sia di performance e carico che di verifica della qualit. Generalmente questa macchina deve essere una sorella di una eventuale macchina di produzione, in quanto, soprattutto nel caso dei test di performance e carico, deve fornire dati che possano essere messi in relazione con la macchina di produzione. In un ambiente pi complesso sarebbe in realt necessaria unaltra macchina, detta di staging, sorella gemella dellambiente di produzione. In questo caso fondamentale che la similarit delle due macchine sia la pi vicina possibile, sia per quanto riguarda lhw che il sw. Questo perch ogni applicazione che deve girare sullambiente di produzione viene prima installata nellambiente di staging, verificando che non ci siano conflitti con le altre applicazioni e che la macchina risponda come atteso. Solo dopo la certificazione nello staging, il software viene installato in produzione. Date le nostre esigenze, lambiente di staging non tuttavia ancora necessario e quindi non labbiamo implementato. Lambiente di produzione invece costituito da macchine in hosting, cos da non avere in casa le problematiche di manutenzione legate alla gestione dei server virtualmente 24x7. Per quanto riguarda il sistema operativo dei server abbiamo scelto (e in questo caso il costo non stato il fattore determinante) di usare Linux. La macchina di QA invece pensata per essere formattata in qualunque momento e riconfigurata con uno specifico sistema, nellottica di eseguire il testing su una qualsiasi piattaforma supportata.

ancora pi importante che per lavora dietro le quinte: il version control system). Siccome ogni sviluppatore pi produttivo con leditor che preferisce, allinterno del team non si imposto nessun editor particolare. Ovviamente, anche in questo caso ci si pu dotare di ottimi strumenti shareware, tra cui, per quanto riguarda gli editor, molto utilizzati sono UltraEdit [1] e TextPad [2]. Io sono particolarmente affezionato a TextPad, mentre Fabione, colonna portante del reparto tecnico, usa UltraEdit. In aggiunta a TextPad, il mio IDE preferito NetBeans [3], completamente free e open source e che viene addirittura fornito in bundle con la JDK 1.4.2. Sebbene la scelta delleditor o IDE sia soggettiva, la scelta dello stile di programmazione non lo del tutto (so che questo far drizzare un po le orecchie, ma vedremo pi avanti nellarticolo perch) ed importante che lo strumento selezionato abbia alcune funzionalit di base, in particolare legate alla formattazione e al formato del testo: possibilit di gestire i diversi tipi di a capo e diversi tipi di spaziatura (solo spazi, solo tab, dimensione dei tab, conversione di tab in spazi).

Version Control System

Il version control system un altro fido amico del programmatore. costituito da un repository centrale di tutti i file relativi ai progetti con lo scopo di tenerne sotto controllo le varie versioni. Quando un file viene inserito per la prima volta nel repository, ne costituisce la versione iniziale. Un file nel repository pu essere estratto e parcheggiato sul proprio ambiente di sviluppo locale con una operazione di check out. Il file cos ottenuto editabile dal programmatore che, a modifiche ultimate, pu reinserirlo nel repository con una operazione detta di check in. In questo caso, il version control system, non inserir in repository lintero file, ma le sole differenze tra la nuova versione e quella precedentemente memorizzata. Inoltre, al nuovo file viene associato un nuovo numero di versione (es: da 1.1 a 1.2). Luso di un version control system apporta notevoli vantaggi in un ambiente di sviluppo multiutente: pi sviluppatori possono lavorare contemporaneamente sulla stessa base di codice; si ha sempre un repository centrale del codice, cosa che ne rende pi semplice la gestione e il backup; in qualsiasi momento possibile recuperare una precedente versione di un file o di un intero build. Ci sono molti software di version control, anche free o open source. Uno dei pi utilizzati e affidabili proprio un software open source dal nome CVS [4] (concurrent version system), che per altro preinstallato e pronto alluso con Linux (selezionando i componenti di supporto allo sviluppo). CVS unapplicazione client/server, costituito cio da una componente server, da installare su una macchina condivisa, e una componente client da installare sul proprio pc di sviluppo. Client e server comunicano via rsh (remote shell), cio lanciando lesecuzione dei comandi di CVS sul server dalla postazione client remota. La dotazione minimale di CVS prevede una serie di comandi da eseguire da una shell, disponibili per moltissime piattaforme. Per esempio, cvs ci <nome-file> serve per fare il check in di un file, mentre cvs co <nomefile> usato per fare il check out. anche possibile lavorare a livello di directory e ricorsivamente, cos che una stessa operazione sia applicata a un intero albero
Computer Programming n. 134 - Aprile 2004

Editor e IDE
Non c amico pi fedele di uno sviluppatore che il suo editor o IDE (in realt, per quanto mi riguarda ce n uno 20

Professione informatico

di directory. Considero il fatto di poter effettuare tutte le operazioni di gestione dei file via linea di comando un pregio e non un difetto di CVS. Infatti, questo consente di automatizzare le procedure di gestione con dei semplici script di shell che possono essere eseguiti in modo non supervisionato e magari schedulati regolarmente. Una diatriba sempre viva nel contesto dei sistemi di versioning legata alla possibilit di fare il check out esclusivo di un file da parte di uno sviluppatore. In questo caso, finch la persona che ha fatto il check out non fa il check in della nuova versione o non rimuove deliberatamente il lock, il file non pu essere modificato e soprattutto inserito nel repository da altri. il caso di Microsoft Source Safe, per citare un version control system sicuramente molto diffuso. CVS invece non ha funzionalit di check out esclusivo e non per limitazione del software, ma per scelta. Infatti CVS adotta una strategia che in campo database si definirebbe ottimistica: pi persone possono lavorare sullo stesso file contemporaneamente effettuando un merge delle differenti versioni quando necessario a check in time. Per spiegare meglio questa problematica, si supponga che due sviluppatori facciano il check out dello stesso file, unfile.txt ver. 1.3, la mattina arrivati in ufficio. Entrambi lavorano sul file e quando hanno terminato ne fanno il check in. Ovviamente uno dei due lo far prima dellaltro, nel qual caso sar un normale check in che porta la versione del file nel repository a 1.4. Quando il secondo programmatore fa il check in della propria versione, ecco che sorge un conflitto: infatti si sta cercando di inserire nel repository una nuova versione di unfile.txt:1.3, ma nel repository gi presente unfile.txt:1.4! CVS tenta quindi un merge, ossia compara le differenti versioni e tenta di applicare le opportune differenze per ottenere alla fine unfile.txt:1.5. A volte per il merge non possibile, in quanto entrambi gli utenti hanno modificato le stesse parti del file; in questo caso necessario lintervento del programmatore che deve ispezionare il risultato del merge e applicare le opportune correzioni. Questa strategia ottimistica perch presuppone che le situazioni di conflitto siano poco probabili, cosa abbastanza sensata perch gli sviluppatori tendono a lavorare su unit di lavoro differenti. Ma soprattutto non si hanno tutti quei conflitti originati dal semplice fatto che si effettutato un check out esclusivo dimenticandosi di rimuovere il lock il giorno prima di partire per le ferie. Personalmente preferisco lapproccio di CVS, anche considerato il fatto che una minimale disciplina di sviluppo (che vedremo fra poco) minimizza il problema dei merge. Unaltra importante funzionalit di CVS il tagging delle versioni: possibile assegnare a singole versioni di file allinterno di un progetto una stessa etichetta, cos da creare un legame tra essi. Per esempio si possono contrassegnare tutti i file (e le specifiche versioni) che costituiscono il build quotidiano del progetto. Si supponga che il progetto MioProgetto sia costituito dai seguenti file: src/java/MioFile1.java src/java/MioFile2.java readme.txt La versione iniziale del progetto potrebbe essere cos costituita: src/java/MioFile1.java:1.1 src/java/MioFile2.java:1.1 readme.txt:1.1
Computer Programming n. 134 - Aprile 2004

Possiamo quindi creare un tag mio_progetto_1_0 che rappresenta MioProgetto ver 1.0: src/java/MioFile1.java:1.1 mio_progetto_1_0 src/java/MioFile2.java:1.1 mio_progetto_1_0 readme.txt:1.1 mio_progetto_1_0 Tuttavia, lo sviluppo del progetto continua finch finalmente si giunge alla release 2.0. Supponiamo che lo stato del repository alla versione 2.0 sia: src/java/MioFile1.java:1.1 mio_progetto_1_0 src/java/MioFile2.java:1.8 src/java/MioFile3.java:1.4 readme.txt:1.2

Si noti che MioFile1.java rimasto invariato e possiede quindi il tag precedentemente associatogli. Gli altri file sono stati modificati o sono nuovi e, quindi, in quella particolare versione non hanno nessun tag. Creiamo quindi il tag mio_progetto_2_0, ottenendo il repository: src/java/MioFile1.java:1.1 mio_progetto_1_0, mio_ progetto_2_0 src/java/MioFile2.java:1.8 - mio_progetto_2_0 src/java/MioFile3.java:1.4 - mio_progetto_2_0 readme.txt:1.2 - mio_progetto_2_0 Linterpretazione abbastanza intuitiva: MioFile:1.1 appartiene a entrambe le release di MioProgetto, mentre, nel caso per esempio di MioFile2.java, MioProgetto v1.0 contiene MioFile2.java:1.1, mentre MioProgetto v2.0 contiene MioFile2.java:1.8. Naturalmente i comandi di CVS permettono di lavorare su una specifica revisione di un file, specificandone la versione, la data di check in o un tag. Dato lo spazio limitato dellarticolo, non possibile approfondire ulteriormente luso di CVS in queste pagine; invito chi fosse interessato a consultare la documentazione disponibile sul sito ed eventualmente a installarlo e toccare con mano. Ho accennato prima al fatto che CVS usa uninterfaccia a linea di comando per eseguire i comandi di check in, check out, ecc. Fortunatamente, non la sola interfaccia disponibile, ma ce n una completamente grafica per gli ambienti Windows. Si tratta di WinCVS [5], anchessa frutto di un progetto open source ospitato su SourceForge [6]. In Figura 1 possibile vederne uno screenshot. Un altro utile tool riguardante CVS che abbiamo installato sul web server interno ViewCVS [7]. Installato come CGI, permette di navigare il repository CVS via web con un normale browser. Lo trovo molto utile per avere immediato accesso alle varie versioni, tag e contenuti dei sorgenti. ovviamente un progetto open source utilizzato dallo stesso SourceForge (Figura 2).

Bug tracking system

Per quanto bravi possano essere i programmatori, non riusciranno mai a sviluppare software privo di bachi, anche solo per il fatto che a volte il confine tra baco e diversa funzionalit non cos netto. sempre bene diffidare di chi ritiene di potersi ricordare i vari malfunzionamenti riscontrati e quindi sistemarli a memoria. Uno strumento per mantenere un database dei bachi fondamentale anche per piccoli progetti e anche quando c un solo sviluppato21

FOCUS

FIGURA 2 CVSWeb

re. Non solo utile per ricordare i malfunzionamenti da sistemare, ma anche per poter avere quando serve una visione di insieme, assegnare i task agli sviluppatori, dare la giusta priorit ai problemi. assolutamente controproducente sistemare un baco, anche complesso, che solo il 10% degli utenti riscontra quando una semplice, ma fastidiosa anomalia si manifesta a tutti gli utenti appena avviato il programma. Affidarsi alla sola memoria quantomeno rischioso. Per questo importante avere un sistema di bug tracking. Esso pu essere molto semplice, come un normale foglio Excel, o molto complesso con funzionalit di change management e reporting. Nella scelta dello strumento pi adatto alla propria soluzione, un fattore importante da considerare che sia facile e immediato da utilizzare per gli sviluppatori. Infatti, un meccanismo troppo complesso e tedioso tende a far s che gli sviluppatori lo usino controvoglia e quando costretti, minimizzando i benefici che ne derivano. I programmatori devono invece vederlo come ulteriore amico. Poteva non esserci un software open source di bug tracking? Ovviamente no! Anzi, ce ne sono diversi, pi o meno complessi, alcuni con integrate funzionalit di project management e quasi tutti utilizzabili via web. Tuttavia dopo qualche ricerca, sono giunto alla conclusione che il prodotto pi adatto per il nostro ambiente di sviluppo sia Bugzilla [8]. molto completo, ma al contempo facile da usare; accessibile via web e salva i dati in un database MySQL [9] cos che se in futuro ci sar la necessit di fare del reporting sar sempre possibile interrogare il db. Lunico punto a sfavore di Bugzilla linstallazione: sebbene sia piuttosto semplice, ho avuto qualche problema nel trovare e scaricare tutti i moduli Perl necessari. Al momento comunque funziona egregiamente e non mi ha dato nessun tipo di problema.

PostgreSQL [10] e MySQL [11]. stato sufficiente attivarli e creare i database e gli schemi necessari per essere operativi. MySQL senzaltro uno dei pi conosciuti, perch utilizzato in moltissime applicazioni web. un database open source che tuttavia, fino a poco tempo fa, soffriva di notevoli mancanze dal punto di vista relazionale (per esempio le transazioni) che lo rendevano utilizzabile soprattutto per basi di dati in sola lettura. Per le esigenze di molti siti web questo approccio pi che sufficiente e consente una maggiore velocit di esecuzione, grande punto di forza di MySQL. Dalle ultime notizie reperibili sul sito, sembra che le ultime versioni di MySQL utilizzino un nuovo motore relazionale, chiamato InnoDB, avente tutte le caratteristiche richieste a un RDBS che si rispetti. In pi, promettono prestazioni veramente eccezionali, anche comparate a prodotti commerciali molto pi conosciuti. PostgreSQL un altro RDBMS open source. pi anziano e maturo di MySQL e ha da sempre tutti i costrutti transazionali e relazionali che portano a considerarlo un ottimo e robusto DBMS. Le prestazioni sono in alcuni casi inferiori a MySQL, ma il fatto di esistere da parecchio tempo d maggiori garanzie di affidabilit, cosa che considero fondamentale per applicazioni pi critiche (come il portale). La decisione che ho preso quindi di utilizzare MySQL quando esplicitamente richiesto, ma PostgreSQL come piattaforma standard per applicazioni critiche. Questo con il proposito per di fare una pi approfondita analisi di prestazioni comparando i database su unapplicazione reale.

Application Server
Il software che sviluppiamo principalmente costituito da un middleware eseguito lato server e da un portale web, cio il tipo di software che meglio si adatta ad essere eseguito allinterno di un application server. In questo ambito la piattaforma scelta basata sullo standard J2EE, per motivazioni sia tecnologie sia di know-how. Anche nel campo degli application server J2EE le possibilit di scelta sono numerose, sia nel campo dellopen source, sia in quello commerciale. Inoltre, anche molti ambienti commerciali permettono luso free dei loro software per scopo di sviluppo. Tuttavia, avendo anche la necessit di distribuire il nostro prodotto in una versione a basso costo e soprattutto facendo un bundle unico con lapplication server per chi non ne avesse gi uno in casa, la scelta caduta su un prodotto open source: JBoss. Questultimo un prodotto tecnologicamente avanzato e molto semplice da installare e usare, utilizzato da milioni di utenti nel mondo: insomma, risponde adeguatamente a tutte le nostre esigenze.

Project build
Ho pi volte accennato al build o al processo di build. Con la parola build, intendo una specifica versione completa del progetto. Questo significa preparare tutto quello che serve per creare una versione del prodotto software che pu essere distribuita o installata sul sistema finale. Il processo per arrivare a tale risultato per un progetto non banale, generalmente costituito da diversi passi, che vanno dalla compilazione dei sorgenti alla generazione della documentazione, fino allimpacchettamento di tutto in un file distribuibile. Nulla vieta che alcuni o tutti questi passi possano essere eseguiti manualmente ricordandoseli a memoria; ma state sicuri che se anche un solo passo richiede lintervento
Computer Programming n. 134 - Aprile 2004

Database
In ogni ambiente di sviluppo non si pu fare a meno di un database. Non tanto per esigenze dellambiente in s (anche se software come Bugzilla in realt insistono su un database relazionale), quanto per il fatto che le applicazioni che si vanno a sviluppare hanno generalmente bisogno di una base dati. Anche in questo caso la scelta di Linux come piattaforma di sviluppo si rivelata molto comoda. Infatti, nella distribuzione standard sono gi presenti i database 22

Professione informatico

umano, ne rimpiangerete lesistenza la prima volta in cui dovrete produrre un hot fix che deve andare in produzione entro 15 minuti. Inizierete a cercare il foglio dove avete scritto le istruzioni (e gi questo potrebbe essere un ostacolo!) e a digitare i comandi uno a uno, sbagliandone il 90% e senza avere la certezza che tutto sia corretto. Ritengo quindi fondamentale avere un processo di build eseguibile senza lintervento di un operatore, cos che possa essere completamente automatizzato ed eventualmente anche schedulato. Non raro infatti che per un progetto su cui lavorano pi persone si scheduli un build notturno che faccia un check out completo dellultima versione del progetto dal CVS e produca il file di distribuzione o addirittura faccia il deployment direttamente sullambiente di sviluppo. In questo modo, la mattina seguente gli sviluppatori potranno operare con lultima versione completa del progetto. Un processo di questo tipo comporta unulteriore attenzione da parte degli sviluppatori: tutto ci che inseriscono nel repository del CVS non deve interrompere in alcun caso la procedura di build. Torneremo su questo aspetto quando parleremo di processo di sviluppo. Una considerazione da fare in questa area riguarda gli ambienti di sviluppo. Infatti, per quanto ricchi di funzionalit di project building, generalmente non forniscono mai uninterfaccia anche a linea di comando, che possa per esempio essere utilizzata in uno script. Per questa ragione non ritengo questi strumenti adeguati per il processo di build: essi richiedono sempre che uno sviluppatore prema il preposto bottone o selezioni la necessaria voce di menu, oltre che essere fortemente focalizzati ai semplici sorgenti. Uno strumento che trovo molto utile per risolvere buona parte di questi problemi Ant [12]. Come gi descritto in un precedente numero di Computer Programming, Ant un tool di build basato su Java estremamente flessibile e potente, con una serie di funzionalit di base che coprono la stragrande maggioranza delle esigenze di build, anche di progetti complessi. Pu inoltre essere esteso con dei task custom, sviluppati appositamente per una particolare esigenza; per esempio, un custom task da noi realizzato ci consente di automatizzare il processo di test di protocollo del nostro server SyncML. Luso di Ant poi coadiuvato da uno o pi script di shell che permettono di assemblare facilmente a un pi alto livello lesecuzione di pi task del processo di build.

Processo di sviluppo
In questa sezione tratter alcune regole di comportamento che bene introdurre nel team di sviluppo al fine di lavorare al meglio con gli strumenti presentati. opportuno comunque sottolineare che questo tipo di regole deve essere condiviso e concordato con il team di sviluppo e non essere imposto. Una procedura di particolare importanza quella che riguarda il processo di sviluppo e di build in presenza di una gestione centralizzata dei progetti tramite un version control system. Il presupposto da cui partire che in ogni momento lo stato di un build sar diverso dallimmagine che si ha in locale sulla propria macchina di sviluppo. Questo perch pi sviluppatori fanno il check in del proprio lavoro in momenti diversi. quindi importante che ognuno riporti le proprie modifiche appena possibile in CVS e faccia un nuovo check out di tutto il progetto tendenzialmente ogni mattina prima di iniziare il lavoro. Partendo quindi da una situazione stabile, ogni singolo sviluppatore esegue le proprie modifiche e finita ununit di lavoro, ne fa il check in. Con finita ununit di lavoro si intende terminato lo sviluppo di una funzionalit, la correzione di un baco, la modifica di un file di testo, ecc., essendo comunque sicuri di almeno due cose: 1) che dopo il check in, il build di un check out completo del progetto vada a termine senza errori; 2) che le proprie modifiche raggiungano lo scopo per le quali sono state introdotte e non entrino in conflitto con altre modifiche fatte da altri. Il primo punto di particolare importanza perch avere un build rotto significa che la mattina successiva nessuno potr eseguire la nuova versione dellapplicazione prima che il build venga sistemato. Quando il team inizia a essere composto da tre o quattro unit, bene identificare un build master che si assicuri che tutte le operazioni riguardanti il processo di build siano state effettivamente attuate con successo. Una strategia che si pu adottare per disincentivare in modo simpatico il check in di modifiche che corrompano il build quella di investire del ruolo di build master proprio il responsabile delle modifiche che hanno corrotto lultimo build.

Backup
Nel campo dello sviluppo software, eseguire un periodico backup dei dati equivale a salvaguardare la quasi totalit di ci che viene prodotto ed quindi unattivit di vitale importanza. Nel nostro caso, un ruolo centrale ricoperto dal file server, che abbiamo appositamente configurato con due dischi uguali ma fisicamente distinti, cos che in caso di crash di un disco sia facilmente possibile rimettere in piedi il sistema con il secondo. Allo stesso tempo il secondo disco viene utilizzato anche come unit di backup dove ogni notte viene fatto un dump dei file system di sviluppo. Settimanalmente poi, un dump viene riportato direttamente su tape, cos da averne una copia su un dispositivo asportabile da conservare in luogo diverso dal server. Il dump e leventuale restore vengono eseguiti con gli omonimi comandi di Linux. Per esigenze pi complesse val la pena di citare Amanda [13], un software di backup client server molto utilizzato e anchesso open source.
Computer Programming n. 134 - Aprile 2004

Ant un tool di build

basato su Java estremamente flessibile e potente
Venendo al caso particolare delluso di CVS, importante introdurre unaltra buona abitudine. Prima di fare il check in delle proprie modifiche bene fare un query update del build. Con la funzionalit di query update possibile verificare lo stato di tutti i file del progetto, evidenziando quelli modificati localmente, quelli invece modificati nel repository centrale e quelli eventualmente modificati sia centralmente sia localmente. Quesultimo caso rappresenta uno dei conflitti di cui abbiamo parlato precedentemente. quindi necessario che lo sviluppatore esegua prima un update della nuova versione del file e 23

FOCUS
quindi applichi le proprie modifiche su questultima. Lasciare questo compito a CVS non certamente una best practice e comunque non risolutiva in tutti i casi (in alcuni casi CVS richiede comunque lintervento umano). Si tenga comunque presente che nulla pi efficace che il parlarsi allinterno del team, chiedendo luno allaltro se si sono fatti nuovi check in o modifiche significative. Ci pu sembrare una banalit, ma ho lavorato per mesi in un team di sviluppo piuttosto numeroso dove uno dei problemi principali legati alluso di un version control system era proprio la mancata comunicazione tra i membri del gruppo di lavoro. Una seconda buona abitudine quella di avere sempre una lista dei task da eseguire. Lo scopo di questa lista non di tenere traccia di chi fa cosa e in quanto tempo, ma di avere sempre sottocchio la lista di cose da fare e che si sono fatte con i relativi tempi stimati e tempi di realizzazione. Un foglio elettronico pi che sufficiente, basta inserire le seguenti colonne: task e subtask, tempo stimato, tempo passato (ad oggi), tempo impiegato (a concludere il task), data inizio, data fine. Lo scopo di mettere date e tempi non tanto quello di tener traccia della produttivit degli sviluppatori, quanto quello di esercitarsi a dare delle stime il pi possibile precise dei tempi di realizzazione dei task. Il fatto di avere sottocchio la storia precedente consente di avere un riferimento nel fare le nuove stime. Infine, unultima linea guida per quanto riguarda i bachi. Abbiamo gi detto della fondamentale importanza del sistema di back tracking; questo torna molto utile nel processo di sviluppo perch in molti casi preferibile risolvere prima i bachi e poi implementare nuove funzionalit. Infatti c la tendenza a considerare il bug fixing non compreso nei task e nelle deadline da completare e raggiungere (anche perch la segnalazione avviene in una fase avanzata dello sviluppo del software). Soprattutto in caso di scadenze molto ravvicinate e sotto stress c quindi la tendenza a scrivere pessimo codice tanto per non fallire la scadenza, con la conseguenza di trasformare semplicemente un task nella tasklist in un baco che verr comunicato successivamente. Inoltre sviluppare nuovo codice su una base di codice malfunzionante non pu che aumentare la fragilit e linstabilit dellintero build. Senza contare che aggiustare un bug sfuggito nello sviluppo di qualche giorno addietro richiede meno tempo che non sistemarlo dopo alcuni mesi. Per queste ragioni una metodologia che pu essere adottata quella dello zero defects, non intesa come lo sviluppo di codice senza bachi, ma come dare massima priorit alla risoluzione dei bachi, pi ancora che allo sviluppo di nuove funzionalit. con una riformattazione automatica, ma poi sar lo sviluppatore originario a non vedere pi il file in modo corretto. Spesso si tratta di piccole cose, ma che infastidiscono molto i membri del team. Il principio che quanto pi si lascia libert di scelta dei tool di sviluppo, tanto pi importante la condivisione degli standard di codifica. In pi, la stesura di specifiche di codifica consente di condensare in poche regole lesperienza di buona programmazione degli sviluppatori pi anziani a tutto beneficio dei nuovi arrivati. Gli standard di codifica possono descrivere moltissimi aspetti della programmazione, dalla stesura dei file sorgente, alluso di particolari costrutti di programmazione, a convenzioni sui nomi di variabili e procedure, ecc.: definiscono quindi uno stile di programmazione che diventer lo stile del team. Ecco alcuni punti che possono essere trattati: Creazione dei file sorgente (intestazione, struttura di directory, commenti iniziali, ecc.). Convenzioni sui nomi per: Classi Metodi Variabili Costanti Commenti Stile di scrittura Lunghezza delle linee Spaziatura e tabulazioni Indentatura Uso delle parentesi Logging Gestione delle condizioni di errore

Conclusioni
In questo articolo si visto un possibile modo di organizzare un ambiente di sviluppo in termini di sistemi e software necessari. Si mostrato come ci sia possibile utilizzando software open source e quindi a costo zero. Si noti che non stata effettuata una specifica ricerca di software free, ma semplicemente i tool pi comunemente utilizzati sono anche disponibili a tutti senza nessun costo. Il vantaggio di poter trovare unenorme comunit di utenti che ha gi affrontato e risolto le stesse problematiche, si manifesta in unestrema facilit di settaggio dei vari software e di risoluzione dei problemi. Inoltre, ladozione di un sistema operativo come Linux consente di avere disponibile in ununica installazione gran parte di ci di cui si ha bisogno.

Standard di codifica
Unaltra disciplina che ritengo importante quella di aderire a standard di codifica. Sono convinto che ogni team di lavoro debba elaborare degli standard di codifica che ogni sviluppatore deve poi seguire nella stesura del codice. Ancora una volta lo scopo non quello di imporre un inutile e fastidioso formalismo, ma quello di prendere atto che lo sviluppo del software in un ambiente multisviluppatore deve adottare delle semplici regole che consentano il pi possibile a tutti i membri del gruppo di essere subito produttivi al 100% anche quando lavorano su codice sviluppato da altri. Quante volte vi capitato di aprire un file e non vederlo correttamente semplicemente perch stata utilizzata una tabulazione diversa da quella del vostro editor? In casi semplici molti IDE vengono in aiuto 24

RIFERIMENTI
[1] http://www.ultraedit.com [2] http://www.textpad.com [3] http://www.netbeans.org [4] http://www.cvshome.org [5] http://www.wincvs.org [6] http://sourceforge.net [7] http://viewcvs.sourceforge.net [8] http://www.bugzilla.org [9] http://www.mysql.com [10] http://www.postgresql.org [11] http://www.mysql.com [12] http://ant.apache.org [13] http://www.amanda.org

Computer Programming n. 134 - Aprile 2004