Evoluzione di una codebase legacy

codebase legacy

Recentemente abbiamo lanciato harlequinmondadori.it, il portale italiano per la vendita online dei romanzi cartacei e digitali pubblicati da Harlequin Mondadori. Il sito è il risultato della fusione di due piattaforme distinte:

  • harlequinmondadori.it: semplice sito statico, utilizzato come progetto pilota per testare le possibilità di vendita di un determinato brand,
  • eharmony.it: piattaforma ecommerce esistente per la vendita dei romanzi Harmony.

Il progetto è nato dalla necessità di migliorare l’ecommerce, avvicinandolo agli standard odierni per la vendita online incrementando così le conversioni. Dal punto di vista tecnico la sfida non è stata da poco considerando che eharmony.it è uno dei primi progetti di ideato, sviluppato nel 2008 sulla piattaforma eZ Publish.

In questo post vorrei soffermarmi sull’evoluzione dal punto di vista architetturale mettendo in evidenza cosa è cambiato nel corso del tempo e cosa è rimasto costante.

 

eHarmony 1.0: sito istituzionale

La prima versione di del sito istituzionale eharmony.it era principalmente un sito di gestione dei contenuti. La piattaforma infatti prevede una serie di sezioni editoriali/ugc:

  • un blog editoriale,
  • un blog con contenuti generati dagli utenti,
  • una sezione news,
  • una sezione letture online, dove editorialmente venivano pubblicate alcune storie.

Altre sezioni invece venivano alimentate da dati importati da un gestionale:

  • romanzi,
  • autori.

 Infine alcune sezione erano pensate per fornire funzionalità varie:

  • iscrizione ad un servizio di newsletter esterno,
  • ricerca dei contenuti.

Data la natura del progetto e la composizione del team (ai tempi erano presenti uno sviluppatore senior e uno junior) eZ Publish rappresentava una buona soluzione, vista la possibilità di creare contenuti custom, una interfaccia di admin già pronta e la possibilità di estendere le funzionalità tramite estensioni e moduli custom.

L’architettura di eZ Publish 4 è di tipo monolitico, come riportato in figura.

artchitettura di eZ Publish 4.x

 

Non esiste una chiara separazione tra presentazione e logica di business. Il caricamento dei dati avviene tramite funzioni utilizzate nei template. Lo sviluppo del portale in questa prima fase si è dovuto adattare spesso alle capacità dalla piattaforma stessa:

  • varie funzioni di raccolta dati sono state implementate come contenuti del cms,
  • l’ecommerce sviluppato in un secondo tempo ha utilizzato quanto già disponibile, seguendo gli step predefiniti pensati dalla piattaforma,
  • la registrazione utenti ha seguito il flusso predefinito.

Pur ponendo alcuni vincoli a livello di business, l’utilizzo della piattaforma “as is” ha portato vantaggi in termini di time-to-market. Ciò non toglie che abbia posto alcuni problemi dal punto di vista tecnico:

Testabilità

eZ Publish 4 non è stato pensato con la testabilità del codice in mente e risulta molto difficile scrivere test in isolamento. Variabili globali, singleton, chiamate statiche sono all’ordine del giorno nella codebase, portando ad un pattern abbastanza noto ed abbassando la qualità del codice.

Ci siamo concentrati quindi principalmente sui test di integrazione e funzionali. Ispirandoci a quello che hanno fatto altri framework abbiamo sviluppato:

  • un componente per caricare dati di test: leggendo file in formato yaml si occupa di creare il db e caricare i dati, portando il sistema in uno stato noto,
  • un browser per navigare le pagine: in modo da simulare l’interazione dell’utente con il sito.

 In questo modo siamo perlomeno riusciti a scrivere una serie di test che preservassero il comportamento del sistema e le funzionalità implementate. Nonostante questo la build del progetto è risultata da subito particolarmente lenta, costringedoci ad accorgimenti vari per velocizzarla.

Logging

Molte funzionalità sono fornite dalla piattaforma ed il logging di informazioni aggiuntive è una operazione complessa. E’ possibile in linea di principio sostituire o estendere le classi ma con il rischio di rendere più complessa la procedura di upgrade.

Debugging

Nel caso di bug i test, essendo ad ampio spettro, aiutano solo in parte ad identificare le cause. Diverse parti dell’ecommerce utilizzavano il modulo workflow di eZ Publish per eseguire azioni al verificarsi di determinati eventi nel sistema. Sebbene molto potente questa parte è risultata parecchio complessa da debuggare.

Performance

Al crescere del numero di utenti alcune parti del sistema hanno iniziato a mostrare limiti di scalabilità, ad esempio:

  • i moduli di reportistica degli acquisti, che non lavoravano su dati precalcolati,
  • il modulo di ricerca standard fornito da ez.

 

harlequinmondadori: verso una struttura modulare

Il (ri)lancio della piattaforma ci ha dato modo di fare alcune modifiche strutturali che sarebbe stato complesso portare avanti in maniera incrementale.

In particolare abbiamo deciso di:

  • continuare ad utilizzare eZ Publish come piattaforma ma solo per la gestione dei contenuti, evitando scorciatoie che alla lunga hanno portato vari problemi,
  • disaccoppiare le varie parti del sistema creando moduli custom per guadagnare in testabilità, osservabilità, manutenibilità.

 I test scritti ci hanno permesso di andare a fare delle modifiche senza introdurre regressioni sulle funzionalità.
La nuova architettura dell’applicazione ricalca la figura seguente:

moduli custom per disaccoppiarsi da eZ

Di seguito un esempio del modulo che gestisce la vista di un ordine

 

Rispetto alla soluzione di default che prevede di utilizzare funzioni di fetch nella view abbiamo diversi vantaggi:

  • possiamo separare la parte di vista da quella di logica, in un approccio più vicino all’MVC. Il modulo diventa l’equivalente della action di un controller,
  • la logica viene incapsulata in classi di servizio, che possono essere testate a livello unitario e/o di integrazione, come succede ad esempio con la classe BillingAddress,
  • il template torna ad occuparsi solo di visualizzazione.

Una volta presa dimestichezza con questo approccio il tempo per lo sviluppo di un nuovo modulo è grossomodo paragonabile all’approccio tradizionale.

Lesson learned

Ad oggi i nuovi sviluppi che non riguardino la gestione dei contenuti in senso stretto seguono tutti la strada custom. Ma allora che senso ha continuare ad utilizzare una piattaforma se scegliamo deliberatamente di usarne solo una parte? Agli inizi del progetto – quando il team era ancora acerbo ed il dominio sconosciuto – il fatto di ‘fidarci’ della piattaforma ci ha permesso di ottenere risultati in tempi e costi ragionevoli. Oggi con un team più maturo ed esperto cerchiamo di renderci indipendenti il più possibile dalla piattaforma sottostante, per avere una maggiore flessibilità.