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

Condividi

Condividi su facebook
Condividi su twitter
Condividi su linkedin