Utilizzare Spring nelle web application – parte 11

Durante lo sviluppo di un progetto, soprattutto se di tipo commerciale, è essenziale mantenere traccia dell’avanzamento dei lavori. Se da un lato questa attività ruba tempo prezioso allo sviluppo (che inevitabilmente verrà rallentato), è anche vero che i benefici superano di gran lunga i costi. Una comunicazione efficace e tempestiva può davvero salvare la vita ad un progetto, che senza i clienti a cui è destinato rimarrebbe un puro esercizio di programmazione!

Le varie metodologie Agili forniscono diversi strumenti per gestire questa comunicazione e collaborazione fra team di sviluppo, clienti, utenti finali, management. In questa sede ci limiteremo ad evidenziare:

  • cosa è stato fatto, ovvero: quanti degli use case inizialmente previsti sono stati effettivamente realizzati?
  • problemi riscontrati;
  • eventuali cambiamenti delle specifiche;
  • prossimi sviluppi;
  • varie ed eventuali.

Questa “scaletta”, come qualcuno potrebbe notare, sembra proprio un ordine del giorno per la classica riunione del lunedì in azienda… e in effetti lo è! Immagineremo quindi di essere tutti riuniti in una stanza virtuale a discutere del progetto.

Cosa è stato fatto

Nel secondo articolo di questa serie abbiamo steso un documento di specifica composto dagli schizzi (mock) delle schermate, accompagnati da descrizioni testuali. Di questi use case abbiamo realizzato:

  • “Use case #1: homepage”:
    • template di pagina, utilizzato da tutta l’applicazione;
    • menu, con i link alle varie pagine anche se non ancora implementate;
    • contenuti: tabella con gli annunci recenti;
    • non è stato ancora implementato il link e relativo feed RSS.
  • “Use case #3: dettaglio annuncio”: la pagina non esiste ancora, ma sono state realizzate le funzionalità ad essa necessaria negli strati DAO e Service (metodo getInsertion() in InsertionService e InsertionDao).

Problemi riscontrati

Nascondere i problemi non è la scelta giusta, sul lavoro come (è una nostra opinione) nella vita. Quando si sviluppa software il rischio è di far aumentare il cosiddetto “debito tecnico” (technical debt) che, come tutti i debiti, prima o poi dovrà essere saldato con gli interessi!

I problemi maggiori si sono potuti osservare nella gestione del build; Maven è un sistema molto sofisticato e complesso, inoltre il suo buon funzionamento non dipende solo dalla correttezza di Maven stesso ma anche da altri fattori come: corretta gestione delle librerie da parte dei repository, preparazione degli sviluppatori che lo usano, affidabilità delle infrastrutture che lo sorreggono. Nel nostro caso è successo che, a progetto già iniziato e ad articoli già pubblicati, ci siamo accorti che una dipendenza (javax:javaee-api:6.0-SNAPSHOT) non era corretta. Abbiamo quindi deciso di non correggere “silenziosamente” gli articoli passati, perché in questo modo non saremmo riusciti avvisare i lettori in maniera efficace; abbiamo quindi optato per una soluzione il più possibile completa:

  • abbiamo inserito un avviso negli articoli incriminati;
  • abbiamo spiegato la situazione nell’articolo n.7, quando è avvenuta la scoperta del problema;
  • sempre nell’articolo n.7 abbiamo fornito un archivio zip contenente il progetto completo, come realizzato fino a quel punto.

Cambiamenti di specifiche

Non essendo un progetto “vero”, ovvero con dei clienti reali che bussano ogni giorno alla porta… ehm all’email con nuove richieste, ripensamenti, furbate e fraintendimenti, il problema delle “specifiche mobili” non è molto sentito, ma potremmo provare a simulare questa situazione in futuro.

Prossimi sviluppi

Nei prossimi articoli procederemo con l’implementazione di altri use case, possibilmente affrontando aspetti il più possible eterogenei fra di loro.

Linkografia