Se avete un paio di minuti di pausa, vi consiglio questo curioso post di Paolo Attivissimo e la serie di commenti che includono affermazioni (e divagazioni) tecniche, umoristiche e filosofiche!!!
Dalla frase "quel che non c'è, non costa e non si rompe", sono riuscito anche a spuntare una riflessione personale...
Spesso esprimo il mio dissenso verso l'introduzione di un tool di terze parti nello sviluppo di una soluzione se in realtà ciò che serve é solo una piccola percentuale delle funzionalità che vengono offerte dal tool.
Secondo il mio parere é molto meglio (se rientra nelle proprie capacità ovviamente) scriversi una propria libreria riutilizzabile generalizzando per quanto possibile il problema.
I motivi, a mio avviso, sono i seguenti:
- se di un tool esterno utilizziamo il 10% delle funzionalità, ci portiamo comunque dietro il 100% delle eventuali vulnerabilità
- presumibilmente quel 10% di funzionalità si appoggia su un infrastruttura generale del tool che quindi dobbiamo includere nella valutazione del rischio di instabilità (supponiamo un ulteriore 20% oltre al 10% dato dall'utilizzo delle funzionalità)
- un tool esterno va appreso, conosciuto e snocciolato quanto basta prima di decidere di utilizzarlo in produzione; guardare un esempio del tool e limitarsi ad adattarlo alla propria esigenza, quasi sempre spalanca le porte a grattacapi futuri
- se ad un certo punto il tool dovesse presentare degli ostacoli insuperabili, se si ha a disposizione il sorgente ci si può anche eventualmente assumere la responsabilità (da non sottovalutare) di apportare delle modifiche a quel tool, se invece non si ha a disposizione il sorgente... game over! Nel caso di una nostra libreria invece, ogni nuova esigenza diventa una opportunità per migliorare e rendere ancora più produttivo il codice che abbiamo scritto, con un continuo refactoring sulla libreria stessa che nel tempo diventerà uno strumento sempre più prezioso.
Mi ha fatto molto piacere quindi sentire da Francesco Cirillo (se non ricordo male) all'Agile Day 2005 che comunque il fatto di preferire la scrittura di codice rispetto all'adozione di un tool (a parità di fattori, ovviamente) è un segno di agilità.
Purtoppo non ho mai trovato il tempo per "studiare seriamente da agile", ma incredibilmente ritrovo molto spesso alcuni di questi principi nel mio modo di lavorare.
Facendo un esempio reale, recentemente ho avuto l'impressione che i tools per implementare la Dependency Injection stiano vivendo un momento di grande diffusione. Bene, significa che sta crescendo l'attenzione verso una architettura migliore; ma negli utlimi mesi molto (troppo) spesso ho appreso che ci sono persone che li utilizzano solo per istanziare degli oggetti inserendone il tipo nel file di configurazione.
Questo secondo me, per le motivazioni di cui sopra, è sbagliato; molto meglio scriversi una funzione, magari in una libreria riutilizzabile, magari utilizzando come esempio di partenza la classe ManagedDesigns.Northwind.Data.DataAccessProviderFactory del NSK.
Quindi, sempre per come la vedo io, va benissimo avvicinarsi ai vari tools per capire cosa hanno da offrire, ottimo il fatto di adottarli se ne abbiamo acquisito una sufficiente competenza per sfruttarne a fondo le potenzialità, altrimenti... valutiamo un bel "Create new project"!
Mamma quanto ho scritto! Forse è meglio se torno a scrivere post demenziali, va... 