Vicolo cieco (informatica)
In informatica, il termine inglese dead end (reso in italiano con l'espressione "vicolo cieco") denota un anti-pattern.
Caratteristiche generali[modifica | modifica wikitesto]
L'anti-pattern "vicolo cieco" si verifica quando, nel corso dello sviluppo di un'applicazione, un componente riutilizzabile esterno al progetto viene modificato. Dato che la modifica è locale al progetto, il costo e la responsabilità della manutenzione del componente modificato si trasferiscono agli sviluppatori dell'applicazione o ai responsabili della sua manutenzione. Una volta modificato, tutti i problemi legati all'utilizzo del componente possono essere addebitati, più o meno giustamente, alle modifiche.
Costi e svantaggi[modifica | modifica wikitesto]
Il vicolo cieco espone il progetto a costi di manutenzione aggiuntivi. Ogni volta che il fornitore aggiorna il componente e ne distribuisce una nuova versione, l'adozione dell'aggiornamento rende necessario integrare nuovamente le modifiche locali nel componente aggiornato. Le nuove versioni del componente possono talora essere incompatibili con le modifiche locali, per cui l'integrazione può richiedere un notevole impegno di riprogettazione e reimplementazione delle modifiche stesse. In alcuni casi, il ricambio del personale e il contenimento dei costi rendono impraticabile la scelta di integrare le modifiche. Quando questo si verifica, l'applicazione è bloccata con una versione non più aggiornata del componente: il vicolo cieco.
Quando il fornitore è esterno all'impresa che sviluppa l'applicativo e produce componenti software disponibili commercialmente, l'anti-pattern vicolo cieco è anche conosciuto come COTS Customization.
Cause e motivazioni[modifica | modifica wikitesto]
La scelta di apportare modifiche al componente riutilizzabile può nascere da forti motivazioni. Gli sviluppatori incaricati dell'integrazione di un sistema software possono avere la necessità di sopperire a limitazioni o caratteristiche inadeguate del prodotto originale. Nel breve termine, le modifiche locali contribuiscono al rapido sviluppo dell'applicazione. Nel lungo termine, però, il costo della manutenzione, necessaria tanto ad ogni nuova versione dell'applicazione, quanto ad ogni nuova revisione del componente da parte del fornitore, diventa inaccettabile.
Eccezioni[modifica | modifica wikitesto]
In alcuni casi, le pratiche che normalmente portano al vicolo cieco possono essere valide e raccomandabili. È questo il caso in cui il responsabile delle modifiche ha preso accordi con il fornitore affinché le modifiche siano integrate nelle future revisioni del prodotto. Questa situazione è più frequente quando gli sviluppatori di applicativi sono aziende che stabiliscono accordi e contratti di fornitura "su misura".
Un altro caso frequente è quello in cui il componente riutilizzabile non è un prodotto commerciale venduto da un fornitore, ma un software open source. In questi casi, non è raro che le modifiche locali, se valide, vengano integrate nella versione ufficiale dall'autore del componente o da una comunità di sviluppatori volontari. In alcuni casi, gli stessi autori delle modifiche fanno parte di questa comunità o sono autorizzati ad integrare le modifiche nella versione ufficiale del componente, cosicché pratiche che normalmente possono portare a un vicolo cieco diventano un valido contributo a un prodotto open source.
Nessuna modifica è, in assoluto, completamente sbagliata. Va sempre considerato il rapporto tra i benefici forniti dalla modifica al componente e il probabile costo del lavoro di manutenzione. Se le modifiche sono ridotte e semplici, mentre i benefici sono notevoli, la scelta può essere accettabile.
Infine, modifiche locali a componenti riutilizzabili esterni possono essere accettabili (perché non danno luogo ai costi e ai problemi discussi) quando l'applicazione sviluppata è un prototipo o uno strumento di ricerca che non richiede manutenzione e aggiornamento a lungo termine.
Soluzioni[modifica | modifica wikitesto]
Il caso più estremo di questo anti-pattern, COTS Customization, ovvero modifiche a componenti riutilizzabili che fanno parte di prodotti commerciali, è da evitare a ogni costo.
Il rischio di incorrere in un vicolo cieco può essere limitato adottando piattaforme di sviluppo standard largamente diffuse, usando componenti disponibili commercialmente (COTS, Commercial Off-The-Shelf) che siano aggiornati dal fornitore regolarmente e frequentemente. In questi casi, è possibile che alcune delle limitazioni dei componenti siano eliminate dagli aggiornamenti.
Se modificare un componente riutilizzabile è una scelta obbligata, è almeno consigliabile realizzare un livello di astrazione che isoli il componente originale dalle modifiche (isolation layer) e separi le dipendenze tra la maggior parte dell'applicazione e le interfacce introdotte dalle modifiche. Il livello di astrazione può essere implementato usando ad esempio il design pattern Adapter.
