Lo scopo dell’astrazione è nascondere la complessità gestita, tramite
l’esposizione di interfacce.
Il problema non è tanto nell’uso della singola astrazione, quanto nel
fatto
che, mediamente, i processi di creazione delle astrazioni adottati fino
ad
ora non ci hanno messi al riparo dalle proprietà emergenti frutto della
“composizione” di più astrazioni.
Queste proprietà emergenti sono a loro volta considerabili come
complessità
e il loro esplicitarsi nei confronti degli utenti della “composizione” è
in
parte considerabile come fallimento delle astrazioni che fanno parte di
tale “composizione”.
Penso che il motivo principale di questa complessità “insostenibile” sia
strettamente legato alla definizione del contesto di applicabilità
dell’astrazione. Può non essere definito o essere definito con troppa
approssimazione ed inoltre l’astrazione potrebbe non rispettare
l’eventuale
definizione fornita.
Prendo come esempio un processo di creazione di un progetto/gemma Ruby:
Nel Gemfile/gemspec possono verificarsi alcune delle seguenti
condizioni:
- per alcune gemme non è presente alcun vincolo di versione;
- per alcune gemme il vincolo di versione non segue il semantic
versioning;
- se anche viene specificato lo spermy operator (Pessimistic version
constraint), alcune dipendenze possono non rispettare il semantic
versioning.
Ok, è possibile utilizzare un sistema di CI, e in tal caso la
responsabilità della definizione del contesto dell’astrazione si sposta
sulla robustezza e completezza della suite di test fornita
dall’astrazione
e dalle suite di test delle dipendenze.
E mi sto riferendo ad un livello molto alto nella “torre della
astrazioni”
disponibili, perché di mezzo ci sono molti altri livelli eterogenei che
interagiscono tra di loro, ad esempio:
- le interfacce del SO usato;
- la configurazione applicata al SO;
- RVM;
- Ruby (interprete);
- Ruby (applicazione).
In ognuno di questi livelli sono presenti problematiche simili a quelle
dell’esempio del progetto/gemma Ruby.
Vedo di buon occhio la direzione intrapresa da progetti come Docker,
perché
l’immutabilità dell’ambiente di esecuzione aiuta a definire in maniera
molto rigida il contesto di applicabilità di un’astrazione.
Aggiungo poi che reputo sia molto utile avere livelli di astrazione
“piccoli” perchè, tra le altre cose, responsabilità limitate comportano
definizioni di contesti di applicazione più robuste.
Il fatto che RVM si sia fatto carico della gestione dell’aggiornamento
dei
certificati SSL https://rvm.io/support/fixing-broken-ssl-certificates
ha
risolto molti problemi a tutti noi, ma tale gestione dovrebbe essere
responsabilità del SO, non di RVM. Come effetto secondario,
l’implementazione di RVM è diventata relativamente più complessa e
conseguentemente anche la definizione del suo contesto di applicabilità,
soprattutto considerando che non è una sua responsabilità.
Potrebbe forse risultare sensato estrapolare in un progetto a parte tale
responsabilità (creando quindi un’astrazione “piccola”),
re-incorporandola
dentro RVM tramite composizione.
Ok, come al solito sono stato logorroico, ma ogni tanto pensare ad alta
voce ci sta 
2015-02-12 12:41 GMT+01:00 Simone C. [email protected]:
