CP pensareprogettareprogrammare n.

134 aprile 2004

I sette sporchi trucchi dello sfangatore

di Massimiliano Bigatti
Siete da soli davanti allo schermo con il cursore lampeggiante e con un obiettivo difcile da raggiungere: come fare a portare a casa la giornata?

Massimiliano Bigatti Non smette mai di stupirsi e di farsi quattro risate con i colleghi. Nel tempo libero scrive per le maggiori riviste, lavora sempre ad un nuovo libro e si occupa del portale dedicato ai Web Services http://javawebservices.it. Ha avuto la pessima idea di certicarsi, tra le altre, come SUN Certied Enterprise Architect for Java Platform 2, Enterprise Edition Technology. Qualcuno ha avuto il coraggio di pubblicare i suoi due libri: Da Visual Basic a Java e Java Web Application. Lo trovate su http://www.bigatti.it.

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

I sette sporchi trucchi dello sfangatore

Siete da soli davanti allo schermo con il cursore lampeggiante e con un obiettivo difficile da raggiungere: come fare a portare a casa la giornata?
di Massimiliano Bigatti

uando il dottore o lingegnere escono dallUniversit, forse immaginano di trovare nel mondo del lavoro un ambiente simile a quello a cui sono stati abituati. La cognizione della dura realt non chiara e distinta, offuscata dallottimismo e dallinesperienza. In quel momento c solo un leggero sospetto, suggerito dallesperienza maturata tramite stage e collaborazioni. Ma, in breve tempo, lingegnere capisce che il mondo reale ben diverso dallambiente ovattato a cui stato abituato per anni. In un dualismo degno di Matrix, da un mondo perfettamente inquadrato (o quasi) delluniversit, lo sventurato si trova, dopo la pillola rossa del diploma o della laurea, nel mondo reale delle macchine, dove la verit che ci si nutre con brodi proteici e si vestiti di stracci. Come direbbe Morpheus, Welcome to the real world. E cos lanalista/programmatore non pi Luca, Marcello o Giovanni, ma diventa una risorsa, da immolare allaltare del Gantt prodotto con Microsoft Project. La risorsa diventa a tutti gli effetti lo sfangatore, la persona che risolve i problemi quotidiani senza troppo badare alla forma, ma puntando alla sostanza delle cose. Nel prosieguo troverete una raccolta di suggerimenti per sopravvivere durante lo sviluppo di progetti per la grande azienda, alcuni dei quali potrebbero sembrare inverosimili. Ma giuro sul Design Patterns di Gamma, che tutto vero. E concordo: alcuni fatti sarebbero davvero divertenti, se non fosse che capitano davvero.

determina la partenza di un determinato progetto. Quando si presenta una opportunit di business, spesso interviene il salumiere. Questa figura, non specifica del mondo informatico, ma tristemente nota in tutti gli altri ambiti degli affari non , come suggerisce il nome, un commerciante al dettaglio specializzato in insaccati. Questa persona si presenta infatti dal potenziale cliente con una serie di prosciutti, cercando di convincerlo ad acquistare un certo bene o servizio. Capita dunque, per il cliente goloso di affettati, estimatore del crudo di Parma o del San Daniele, che un progetto nasca pi per soddisfare questa sua passione per il suino, piuttosto che per una esigenza reale; il confine tra la reale esigenza ed il pretesto si rende quindi pi sfumato. Da questo meccanismo perverso nascono cattedrali nel deserto, progetti che vivono la loro esistenza svincolati dal resto del mondo, monumenti allo spreco di tempo e denaro (del cliente). Se vi state chiedendo a cosa serve quello che state facendo, perch non ovvio, o se il vostro capo vi dice di non preoccuparvi, perch quello che state facendo verr poi buttato, non preoccupatevi. Forse il salumiere passato anche dal vostro committente. Un consiglio per: impegnatevi comunque al massimo. Ne va della vostra esperienza e formazione, aspetti questi la cui unica persona a cui interessano siete voi stessi.

Cattedrali nel deserto

Si potrebbe pensare che un progetto software venga sempre commissionato, pianificato, sviluppato ed installato per risolvere un problema specifico, per fornire una funzionalit, risolvere un problema o migliorare la situazione corrente. Spesso questi assunti non sono completamente veri, o meglio, non sono la forza trainante che

Requisiti chiari, amicizia lunga

Comunque sia partito un progetto, una cosa, invariabilmente, certa: il cliente ha qualche richiesta da fare, e spesso la pi confusa e incoerente possibile. In funzione della dimensione del progetto potreste essere voi ad occuparvi della raccolta dei requisiti utente, oppure potrebbe essere compito del capo progetto, o di qualche altro elemento del gruppo di sviluppo. Questa fase molto critica, perch quella dove vengono formalizzate le richieste dellutente, che costituiscono la base per lo sviluppo del progetto. In questa fase, importante osservare una regola sola: i requisiti devono essere chiari, semplici ed espliciti. Anche se purtroppo non lo saranno mai, spesso perch il cliente non un informatico in grado di svolgere una analisi preventiva delle sue esigenze, e di riassumerle in un documento comprensibile. Inoltre, non gli conviene farlo: meno informazioni fornisce prima, pi in grado di giocarsela dopo, chiedendo implementazioni a cui probabilmente non pensava allinizio. anche uno dei pro25

Massimiliano Bigatti

mbigatti@infomedia.it

Non smette mai di stupirsi e di farsi quattro risate con i colleghi. Nel tempo libero scrive per le maggiori riviste, lavora sempre ad un nuovo libro e si occupa del portale dedicato ai Web Services http://javawebservices.it. Ha avuto la pessima idea di certificarsi, tra le altre, come SUN Certified Enterprise Architect for Java Platform 2, Enterprise Edition Technology. Qualcuno ha avuto il coraggio di pubblicare i suoi due libri: Da Visual Basic a Java e Java Web Application. Lo trovate su http://www.bigatti.it.

Computer Programming n. 134 - Aprile 2004

FOCUS
blemi del modello di sviluppo waterfall, che discipline come lExtreme Programming cercano di correggere: impossibile conoscere a priori, e con completezza ed accuratezza, i requisiti di unapplicazione complessa. Per questo motivo, quando vi viene richiesta una stima, aggiungete sempre un 20% al tempo che pensate di impiegarci e non preoccupatevi: il vostro capo, se un buon capo, aggiunger ancora un altro 20%.

Non superate quella deadline!

Una volta avviato il lavoro, possibile che il gruppo di lavoro si trovi a ridosso delle scadenze, senza avere terminato di realizzare quanto era stato promesso dal management per quella data di scadenza. Le deadline sono infatti un impegno che il fornitore prende di fronte al cliente e che si impegna a tutti i costi a rispettare. Questo a costo di richiedere continui straordinari agli sviluppatori, anche se ci pu non bastare a sviluppare quanto necessario.

Prototipo o prodotto?
Alcune volte, prima di procedere alla realizzazione del progetto, il management richiede al gruppo di sviluppo un prototipo dellapplicazione. La definizione da dizionario di prototipo primo esemplare; tipo originario da cui derivano tutti gli altri: questa definizione viene intesa nello sviluppo del software, che diverso rispetto alla produzione di beni fisici, come la realizzazione di una applicazione che simuli il funzionamento di quella reale. La richiesta del capo quindi quella di mettere insieme unapplicazione alla belle meglio, nel tempo minore possibile e senza attenzione ai particolari. Alcune volte questo lavoro di supporto per convincere il cliente a commissionare il progetto. Nel produrre in fretta il prototipo, si utilizzano tutta una serie di trucchi; ad esempio, in una applicazione che ad un certo punto doveva invocare Internet Explorer, al suo posto si visualizzata una bitmap del browser di Microsoft. Se tutto va bene, ed il progetto parte, ci si potrebbe aspettare che la continuazione logica del lavoro sia quella di eliminare laccozzaglia di codice scritta per il prototipo e ripartire con la progettazione, ma il management non della stessa idea. Ecco che il prototipo diventa il prodotto: sempre con lo sforzo minore possibile. Il prossimo obiettivo quello di implementare le funzionalit mancanti. Le conseguenze sono chiare: come una casa che poggia su fondamenta deboli, il prototipo, improvvisamente promosso a prodotto, fatica a diventare soddisfacente per il cliente. Sebbene da una parte si possa riuscire ad aggiungere le funzionalit mancanti, sono le caratteristiche intrinseche dellapplicazione ad essere carenti. Qualit come laffidabilit, le prestazioni e la manutenibilit, ad esempio. Daltra parte questi sono tutti aspetti che vengono scoperti dal cliente solo in un secondo momento, se il fornitore riesce a scappare con la borsa, bene; ma spesso i progetti, almeno nelle grandi aziende, durano anni, e questi problemi ricadono inevitabilmente su chi ha la responsabilit della manutenzione correttiva ed evolutiva dellapplicazione, che solitamente il gruppo di lavoro stesso che ha realizzato il progetto.

Ne va della vostra
esperienza e formazione, e lunica persona a cui interessano siete voi stessi
A questo punto il management creativo pu venire fuori con soluzioni innovative: 1) Se avreste dovuto sviluppare una routine o una funzionalit, ma non avete ancora realizzato nulla o quasi, implementatene linterfaccia, restituendo un errore. In questo modo il cliente penser che il codice esista, ma che non esegua quanto dovrebbe per via di una anomalia. Questo consente di guadagnare altro (poco) tempo per proseguire lo sviluppo; 2) Se invece lo sviluppo si sta arenando su un baco di difficile soluzione, rilasciate lapplicazione cos com. Sar il cliente a segnalare il problema, sempre che se ne accorga; pu essere che non utilizzi quella determinata funzione per un certo periodo di tempo. In entrambi i casi, la situazione percepita non che le stime erano sbagliate, o il gruppo di lavoro non preparato al compito da affrontare, ma che esiste semplicemente un malfunzionamento nel software, evenienza che con una certa facilit si presenta nelle applicazioni per la grande azienda. In questo modo si guadagna il tempo necessario a risolvere i problemi o a completare lo sviluppo.

Aiuto!
Quando incontrate un problema che non riuscite a risolvere, una soluzione quella di cercare su Internet (vedi il paragrafo Googling). Ma quando proprio non sapete che pesci pigliare, una prassi comune quella di chiedere aiuto, ed in particolare possibile chiedere ai colleghi (possibilmente pi esperti) o su Internet. bene per rispettare alcune regole di bon-ton e di netiquette. Il vantaggio di parlare dal vivo con una persona quello di avere un dialogo con scambi di idee in tempi pi stretti, indispensabili se il problema complesso; con la posta elettronica i tempi si allungano, quindi opportuno porre domande mirate. Daltra parte, se i colleghi possono avere una conoscenza specifica del problema e del contesto, su Internet si possono trovare persone anche pi esperte della media, anche se non detto che siano disposte ad aiutarvi. Questo un punto importante: le altre persone non sono obbligate a rispondere alle vostre domande, anche
Computer Programming n. 134 - Aprile 2004

Bassa qualit del codice

Per questi motivi, il codice ha spesso una bassa qualit. Le aziende raramente costituiscono gruppi di lavoro composti da tutti esperti: preferiscono comporli con poche risorse preparate, a cui vengono affiancati i giovani, che cos dovrebbero ricevere un training-on-job. In funzione dellazienda, il rapporto tra il numero di persone senior e junior e quello tra il tempo ed il grado di difficolt di progetto variano. Uno dei casi peggiori: vengono costituiti gruppi di lavoro con solo un componente senior, quattro junior, per un progetto complesso. Potrebbe essere la storia di un disastro annunciato. Non vivendo nel mondo ideale, purtroppo le risorse sono limitate! 26

Professione informatico

se sono colleghi o sono presenti su Internet. Se lo fanno per farvi un favore, e questo sempre da tenere in considerazione. Alcuni passi da seguire sono dunque i seguenti: 1) se fate una domanda su Internet, ad esempio su un newsgroup o direttamente alla casella postale di una persona che pensate possa avere la risposta che cercate, per prima cosa presentatevi, se non lavete gi fatto. Se scrivete ad una persona, spiegate dove avete trovato il suo indirizzo di posta; 2) siate brevi: i testi lunghi su Internet non sono graditi, come le mail chilometriche; siate concisi, riassumendo la vostra presentazione e quella del problema agli elementi essenziali. Questo vale anche per le domande ai colleghi. Prima di fare una domanda, che un impegno di tempo per il vostro interlocutore, che deve ascoltare, capire ed eventualmente formulare una risposta, necessario svolgere un lavoro di analisi e sintesi; prima di presentare un problema, eseguite tutti i test necessari, facendo tutte le prove del caso. Un esempio, preso dal mondo dellhardware, per capire meglio, questo: come fate per capire dove sta il guasto di un personal computer, ad esempio, se non si accende? Probabilmente seguireste una scaletta simile a questa: 1) verificare se la spina attaccata; 2) verificare la corretta accensione dellunit centrale e del monitor; 3) sostituire la tastiera per vedere se quella che manda in corto il computer; 4) sostituire il mouse per lo stesso motivo; 5) aprire il computer e verificare il funzionamento dellalimentatore; 6) sostituire ad una ad una le diverse schede. La regola generale quindi quella di suddividere il problema in modo da restringere ad ogni verifica, linsieme delle possibilit che possono generare il problema. Ad ogni modo, aspettatevi talvolta una mancata risposta: non detto che chi interpellate sia in grado di rispondervi. Pi aumentate di esperienza, e meglio utilizzate lo strumento Internet, pi facile che le risposte gi pronte le abbiate gi trovate. Se il problema persiste forse qualcosa di molto particolare, a cui non sono preparati neanche i vostri colleghi.

2) utilizzare parole specifiche; 3) includere eventuali messaggi di errore o codici che identificano lerrore; 4) non specificare congiunzioni ed articoli (che vengono ignorati);

Non vivendo nel mondo

ideale, purtroppo le risorse sono limitate!
Unaltra possibilit quella di formulare una domanda, come si ipotizza possa essere stata scritta da qualcuno in passato, in modo da trovare le eventuali risposte gi date; la ricerca pu anche essere estesa ai newsgroup in automatico, tramite laccesso ai gruppi (http://groups.google .it). Ovviamente tutto questo deve essere scritto in inglese, lingua franca di Internet.

Ristrutturazioni
Quando il progetto ad un buon punto dello sviluppo, ci si potrebbe trovare davanti a parti dellapplicazione che necessitano di una riscrittura, magari anche perch il cliente ha formulato nuove richieste, o perch ha cambiato i requisiti in merito a quella funzione. Lesperienza di Extreme Programming ci insegna che non possibile realizzare a priori unapplicazione perfetta, che anticipi tutti i cambiamenti che potrebbero diventare necessari. In questo caso la richiesta del management sempre quella di inserire una pezza, una soluzione brutta esteticamente e progettualmente, che aumenta lentropia del sistema e che dovrebbe avere carattere transitorio; in realt quasi sempre definitiva. A questo punto lo sviluppatore si trova di fronte ad un problema di possibilit di manutenzione: maggiore il numero di soluzioni tampone, maggiore il tempo e la difficolt per aggiungere la correzione n+1. Solitamente per il management non molto sensibile a questi problemi, spesso liquidati come tecnicismi. Sarebbe necessaria una riscrittura, ma la parola rifare o riscrivere non mai presa molto bene, anche perch questa una attivit percepita come lunga in termini di tempo e senza un ritorno immediato di investimento; una possibile soluzione quella, con loccasione di interventi sulla parte di codice incriminata, di inserire modifiche manutentive, volte alla riscrittura anche solo di una piccola parte del sottosistema fuori controllo (refactoring). La stima dei tempi includer quindi la valutazione del refactoring e dellimplementazione vera e propria. Non dunque indispensabile comunicare al management come si applicher la modifica, in questo modo si eviter di spaventarlo, ma si potranno apportare le migliorie che il tempo a disposizione consente.

Googling
Le risposte ai vostri problemi potrebbero gi essere state formulate e memorizzate in quel vasto parco di informazioni che il World Wide Web; esistono infatti una quantit di siti di supporto, forum e weblog che contengono una miniera di preziose informazioni, sugli argomenti tecnici (e non) pi disparati. Per evitare lunghe ricerche in siti diversi, ci viene in aiuto il potente motore di ricerca Google, diventato talmente famoso da creare un neologismo, googling, che significa appunto cercare su Google. Le regole per una ricerca efficiente su questo tipo di motori di ricerca sono oggetto di interi libri, ma le principali sono le seguenti: 1) utilizzare un numero di parole sufficienti (n troppo poche, n eccessive);
Computer Programming n. 134 - Aprile 2004

Conclusioni
Il progetto si avvia cos alla fase finale della sua vita, quella dellinstallazione e della manutenzione, in attesa della prossima affascinante avventura, dove un po di storia si ripeter e dove nuovi episodi dimostreranno come la realt, a volte, riesce a superare la fantasia. Benvenuti, e buon lavoro. 27