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:

• Automation for the People: continuous inspection

Ultimamente in TV c’è una pubblicità che mi piace molto: la pubblicità della Mostra Internazionale d’Arte Cinematografica di Venezia. La frase cardine della promozione, che credo appenderò in ufficio è la seguente:

E’ il desiderio di qualità che ci ha sempre permesso di sognare.

Stamattina ho letto inoltre un post di uno dei miei blog preferiti: AgileAdvice. Il post si intitola Quality is Not Negotiable (consiglio vivamente una lettura) ed affronta il tema della qualità come condizione irrinunciabile ed imprescindibile ad un processo efficiente che minimizza gli sprechi e che voglia ottenere il massimo dal business di cui è a supporto. In caso contrario ci si ritrova ogni 2-3 anni a dover ricostruire da capo sistemi e prodotti, o nel caso migliore (si verifica raramente) a dover fermare la produzione per lunghi periodi di tempo al fine di rimettere ordine in un prodotto mal costruito e di bassa qualità. Mi viene in mente uno dei cardini del Toyota Production System e di tutta la filosofia del Lean Manufactoring: in ogni momento ogni componente del team ha il diritto di fermare la produzione se nota un artefatto di bassa qualità ed in questo caso la produzione non riprende fino a quando tale difetto non sia stato risolto e non se ne siano comprese le cause. Questa continua ricerca di qualità e la responsabilizzazione di ogni sviluppatore garantisce che il mostro venga ucciso in poco tempo quando ancora piccolo e non quando avendo raggiunto dimensioni ciclopiche un suo abbattimento renderebbe necessario un dispendio di forze (=soldi) molto alto; per non parlare degli ingenti danni che tale mostro avrà compiuto durante la sua crescita.

Una delle armi più efficaci in mano agli sviluppatori per identificare il prima possibile questi difetti è l’enfasi su brevi cicli Test Sviluppo Refactoring, in Toyota come nello sviluppo del software.

Per applicare questi brevi cicli e per continuare a sognare il team non può permettersi compromessi, e non deve accettarli da parte dell’organizzazione e del management: sareste disposti a calpestare la vostra dignità e a vivere senza sogni?