Scrivere software di qualità è molto difficile, e tale difficoltà non solo è legata naturalmente alla complessità del dominio, ma anche a fattori più “umani” quali la comunicazione all’interno del team soprattutto quando composto da elementi di esperienza e formazioni eterogenee.
Una serie di tool ci viene in soccorso per monitorare continuamente la qualità del codice che stiamo scrivendo, e se unita alla pratica di Continuous Integration (ad esempio per mezzo di CruiseControl), permette di controllare continuamente e su base regolare se tutti i componenti del team stanno scrivendo software al di sotto degli standard di qualità prefissati. Prevenire problemi di comprensibilità e mantenibilità del codice, affrontandoli per tempo, è possibile rendendo visibili nel workspace le misure di queste caratteristiche, per mezzo di Big Visible Charts o di una Ambient Orb, cioè di una sfera che, comandata da un task di Ant, a seconda della qualità del codice si colora di verde o di rosso acceso.
I seguenti tool di controlli statici del codice permettono di tenere gli occhi ben aperti su questi aspetti:
- CPD (con PMD): identifica le duplicazioni del codice della nostra applicazione da parte degli sviluppatori più ansiosi o meno accorti; comunichiamo abbastanza?
- CheckStyle: verifica che le Code Convention vengano rispettate
- Metrics: riteniamo la programmazione ad oggetti una chimera o ci impegnamo a fondo per comprenderla?
- Clover: stiamo scrivendo abbastanza test?
Articoli:
Noi nel nostro XP team usiamo CruiseControl da molto tempo.
Siamo arrivati al Continous Integration senza conoscerlo come pratica, ma sentendone la necessità.
Vista la complessità del sistema, dettata dall’alto numero di moduli, era facile in principio committare delle modifiche che “rompevano” la build. Questo era dovuto anche a una leggerezza nelll’effettuare delle modifiche senza preoccuparsi del progetto nella sua totalità. Un nostro collega così ha rispolverato Cruise Control visto che lo aveva già usato in altri progetti con notevoli benefici.
Il primo impatto è stato abbastanza doloroso; abbiamo settato il checkout ogni due ore con relativo inoltro di mail a tutto il gruppo di sviluppo, in modo da rendere più responsabili i singoli componenti (visto che venivano riportati gli ultimi commit che avevano rotto la build).
Direi che la pratica ha avuto i suoi ampi vantaggi: a oggi sono circa 6 mesi che non riceviamo più mail minatorie dal nostro “amicone” ^_^.
Il passo successivo sarebbe configurarlo per eseguire tutta la test suite di junit, ma il TDD come pratica non è riconosciuto da tutti i componenti del team, quindi siamo molto a corto di test unitari.
Fortunatamente usiamo una test suite funzionale basata sul nostro framework/environment (JADE) che non sarebbe facilmente configurabile da ant.
Leggendo di recente XP explained ho confermato quello che avevo già provato in campo; le pratiche illustrate alla fine sono frutto di una analisi empirica ed effettivamente non posso che confermarne i vari vantaggi.
Commento di m4zi — 30 Agosto, 2006 @ 10:32 am