E’ una questione di assenza di stile

Qualche giorno fa si parlava dello stile del software davanti a una birra. In particolare la questione era la facilita’ con cui si fa nascere un’interfaccia : c’e’ chi prima di tutto scrive l’interfaccia del componente da implementare, poi scrive l’implementazione, c’e’ chi scrive l’implementazione e appena ha finito ne estrare l’interfaccia, c’e’ chi scrive l’implementazione, usa l’implementazione, vede che tutto funziona e poi estrae l’interfaccia sostituendola all’implementazione per ogni uso; in fine c’e’ chi scrive l’implementazione, la usa, non estrae l’interfaccia, scrive un’altra implementazione per tutt’altra faccenda e si accorge che si puo’ identificare un contratto comune tra i due componenti implementati e a quel punto estrae l’interfaccia per poi procedere alla sostituzione negli usi.
(Una piccola nota di colore : in questo periodo mi trovo a lavorare un sacco su carta. Le stesse sfumature nell’approccio si applicano alla carta cosi’ come ai sorgenti, cambia solo la rappresentazione, basta usare il termine “scrive” con “disegna” e il resto e’ uguale)

Nello scambio di battute ci siamo trovati a identificare gli stili con un paio di maestri : Eric Gamma e Robert Martin. In particolare, guardando Fitnesse e la predilezione per la concretezza delle classi, io parlavo dello “stile di Martin” come quello che fa uscire le interfacce tardi, solo se strettamente necessarie; guardando invece i sorgenti di Eclipse, in cui praticamente ogni concetto viene esposto tramite un’interfaccia ben separata dall’implementazione, mi veniva da parlare dello “stile di Gamma” come quello che definisce l’interfaccia a priori.

Ci ho ripensato un paio di giorni fa.

Quello che stavamo facendo era parlare di diverse sfumature nel processo di creazione del software caratterizzandole con i nomi di creatori di software di cui noi osserviamo soltanto il prodotto finito.

Stupido, stupido, stupido!

Era come se avessi dimenticato di chi stavo parlando. Pensare che uno qualsiasi di questi due maestri lasci trasparire il suo processo di lavoro nel prodotto finito al punto da poter dire “in Eclipse ci sono interfacce ovunque, quindi Gamma scrive subito l’interfaccia” e’ come aspettarsi di capire, guardando la nave completa, come abbia lavorato lo studio di progettazione, con quali modelli, se fisici o simulati, o entrambi, e quanto di frequente.

Cosi’ come i colpi di scalpello dati al modellino in legno non compaiono e non devono comparire nella carena del vascello, pur essendo stati strumentali a crearla, un professionista non puo’ includere nella sua definizione di “finito” nulla che non riguardi strettamente le caratteristiche del sistema richiesto. Se c’e’ una cosa sicura e’ che la sequenza dei singoli passi usati per arrivare alla versione rilasciabile, le caratteristiche del metodo di progettazione, comunque si vogliano chiamare, non hanno nulla da spartire con le caratteristiche richieste dal cliente.

Perche’ Fitnesse e’ molto concreto? Perche’ Fitnesse deve fornire funzionalita’ rapidamente a chi lo usa, la comodita’ d’uso si manifesta quasi unicamente nella velocita’ con cui si riesce a far fare a Fitnesse quello che desideriamo usando il nostro codice. Perche’ Eclipse ha un sacco di interfacce? Perche’ Eclipse e’ una piattaforma che deve garantire miriadi di punti d’accesso che restino, con affidabilita’, uguali a se stessi. Questo non e’ design anticipatorio, tutte quelle interfacce rispettano una necessita’ molto attuale di Eclipse : la possibilita’ per delle terze parti di investire nello sviluppo di prodotti finiti, anche di elevato valore, senza trovarsi a lavorare direttamente con degli “internals” passibili di cambiamento repentino da una minor release all’altra.

Un processo di sviluppo ha un solo modo di fallire : non rispondere alle necessita’ degli utilizzatori; siano questi gli sviluppatori che si trovano a lavorare con i suoi sorgenti o siano gli utenti della sua interfaccia grafica. In nessuno dei due casi la sequenza con cui e’ stato creato il suo progetto puo’ giustificare l’inadempienza. Quindi, per forza di cose, un professionista non puo’ manifestare il suo “stile” nel prodotto finito (che sia una singola storia o un’intera major release di Eclipse), puo’ solo manifestare quanto il suo stile gli dia la capacita’ di rispondere alle esigenze degli utilizzatori (interni ed esterni). Quindi non e’ lo stile che posso identificare, ma la qualita’ esibita (o la sua assenza).

Fitnesse nell’essere concreto sta esibendo qualita’, Eclipse nell’essere disperatamente indiretto esibisce, del pari, qualita’.

Quindi, in via puramente teorica, se lo sviluppatore mira alla perfetta aderenza alle necessita’ del sistema e dei suoi utilizzatori finali, capisce di esservi giunto proprio quando riconosce che lo “stile” e’ svanito, ed ogni idioma, ogni scelta implementativa, ogni nome, e’ riconducibile alla dedizione nel rispondere a queste necessita’, non alle meccaniche usate per giungere a rispondervi.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s