In Salento, anche se mi ero preposto di leggere qualche testo di SQL, ho deciso di approfondire il discorso sui Desing Patterns e sul Database Refactoring. Proprio per questo, mi sono fidato di due testi (a mio avviso veramente interessanti) consigliati dal collega Vincenzo, sempre affidabile in materia di testi da leggere.
Uno è  Design Patterns: Elements of Reusable Object-Oriented Software (http://www.informit.com/store/product.aspx?isbn=0201633612) e l'altro è Refactoring Databases: Evolutionary Database Design (http://www.informit.com/store/product.aspx?isbn=0321293533).
Premettendo che di OOP non sono sicuramente un esperto, devo dire che l'approccio degli autori al tema è veramente ben curato. La lettura, in entrambi i casi risulta di facile comprensione e di ottima qualità. Sicuramente il secondo testo mi ha fornito nozioni che già conoscevo di granlunga, ma la sua lettura è stata comunque molto interessante, se rapportata anche alle mie esperienze lavorative.
In questo ultimo periodo infatti mi sono dovuto scontrare ogni giorno con un vecchio sistema database, la cui stesura, ereditata da terzi e distribuita in ben un decennio di lavoro, ha creato un gigante che ormai necessitava di refacoring in molte delle sue zone. Purtroppo, come accade spesso, le contingenze e le urgenze non hanno permesso un corretto ripensamento di molte funzionalità ma devo dire che molte volte ho "inconsciamente" seguito i pattern corretti di refactoring che anche questo secondo libro indica. Appagante scoprirlo . Molte persone che lavorano accanto al database, come DBA o come developer dovrebbero leggere almeno le prime pagine del suddetto libro. Una corretta applicazione dei modelli indicati permette quasi sempre la riuscita di un affidabile ed efficiente refactoring del proprio database.

C'è una frase all'inizio del libro che continuerà sicuramente ad essere vera e che mi ha colpito, perchè tanti non seguono minimamente la strada indicata in essa:
"When you have a new feature to add to your code, the first question that you should ask is 'Is actual code the best design possible that enables me to add this feature?' If the answer is yes, add the feature. If the answer is no, FIRST REFACTOR YOUR CODE TO MAKE IT TE BEST DESIGN POSSIBLE, and THEN add the feature. On the surface, this sounds like a lot of work; in practice, however, if you start with high-quality source code, and then the refactor it to keep it so, you will find that this approach works incredibly well."

Io credo che seguendo questa via si possa ottenere sempre qualcosa di buono. Senza tralasciare quello che ne nasce implicitamente, ovvero il regression test, da eseguire ogni qualvolta andiamo ad aggiungere una seppur piccola funzionalità. Mai partire da un sistema che già di per sè non funziona correttamente. E credetemi, negli ultimi mesi, mi sono reso conto di quanto un gigante di 10 anni possa avere buchi e lacune senza che nessuno sappia l'origine o il motivo della loro esistenza. Lavorare su un sistema di questo tipo richiede la massima attenzione e disciplina possibile, in modo da renderlo facilmente manutenibile, leggibile e comodo da utilizzare.

Voi che ne pensate?

Stay Tuned!