Vorrei dire due parle su questo argomento anche se non mi sento
propriamente il più qualificato. Leggo molti blog tecnici, e gli argomenti che
vi trovo sono sempre relativi a design pattern, tecniche di sviluppo,
tecnologie, tips e altre cose che fanno parte della visione che ha un normale
programmatore dello svilupo del software. E da un po' che ci penso, ma per
quanto ritenga formidabili certi paradigmi e certe teorie, per quanto ritenga
efficace un pattern nello sviluppo, per quanto ami parlare e sentir parlare di
sviluppo agile, quello che mi sembra da sempre assente è l'obbiettivo finale
dello sviluppo inteso come il riuscir a rispondere correttamente ad una esigenza
indipendentemente dalla tecnologia che si mette in campo per raggiungere
l'obbiettivo.
Un pattern è davvero una bella cosa, elegante, raffinato e
tutto il resto, ma un pattern applicato ad un prodotto di scarsa usabilità, o
incompleto lascia davvero il tempo che trova. E' obbligatorio a mio parere
rivalutare gli aspetti analitici che portano alla realizzazione di un buona
interfaccia, di una buona struttura applicativa di efficaci paradigmi di uso del
software. Tutto il resto è secondario.
Lo so, si tratta di una affermazione forte, soprattutto detta
in un gruppo che disserta quotidianamente di questi aspetti
"secondari", ma davvero la mia sensazione è che troppo spesso ci si
concentri troppo sui mezzi dimenticando o accantonando i fini. Chi sviluppa lo
sa, ci si può concentrare infinitamente sull'architettura di un
applicativo, scrivede del codice elegantissimo, usare le tecnologie
all'ultimo grido, ma se poi un pulsante dell'applicazione risulta troppo piccolo
e scomodo per l'utente finale, tutto il software sarà giudicato alla stregua di
quella stramaledetta distrazione.
Come spesso succede, credo che la soluzione al problema stia
nel mezzo. Esagerare dall'uno o dall'altro lato comporta o la irrimediabile
inusabilità del programma o la inefficacia dal punto di vista tecnico (che
alla fine il più delle volte si traduce altrettanto in inusabilità). Perciò, a
mio parere, il programmatore completo non è colui che conosce a menadito tutti i
Design Pattern, che si è letto tutti i libri sul refactoring, e che conosce come
le sue tasche i meandri di una tecnologia, ma quello che, riesce ad usare al
meglio le sue conoscenze (anche un po' superficiali se volete) per bilanciare i
due aspetti e trarne la soluzione più efficace possibile.