b'\n_START_ARTICLE_\nVicolo cieco (informatica)\n_START_SECTION_\nCaratteristiche generali\n_START_PARAGRAPH_\nL\'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 \xc3\xa8 locale al progetto, il costo e la responsabilit\xc3\xa0 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\xc3\xb9 o meno giustamente, alle modifiche.\n_START_SECTION_\nCosti e svantaggi\n_START_PARAGRAPH_\nIl 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\xc3\xb2 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 \xc3\xa8 bloccata con una versione non pi\xc3\xb9 aggiornata del componente: il vicolo cieco._NEWLINE_Quando il fornitore \xc3\xa8 esterno all\'impresa che sviluppa l\'applicativo e produce componenti software disponibili commercialmente, l\'anti-pattern vicolo cieco \xc3\xa8 anche conosciuto come COTS Customization.\n_START_SECTION_\nCause e motivazioni\n_START_PARAGRAPH_\nLa scelta di apportare modifiche al componente riutilizzabile pu\xc3\xb2 nascere da forti motivazioni. Gli sviluppatori incaricati dell\'integrazione di un sistema software possono avere la necessit\xc3\xa0 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\xc3\xb2, 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.\n_START_SECTION_\nEccezioni\n_START_PARAGRAPH_\nIn alcuni casi, le pratiche che normalmente portano al vicolo cieco possono essere valide e raccomandabili. \xc3\x88 questo il caso in cui il responsabile delle modifiche ha preso accordi con il fornitore affinch\xc3\xa9 le modifiche siano integrate nelle future revisioni del prodotto. Questa situazione \xc3\xa8 pi\xc3\xb9 frequente quando gli sviluppatori di applicativi sono aziende che stabiliscono accordi e contratti di fornitura "su misura"._NEWLINE_Un altro caso frequente \xc3\xa8 quello in cui il componente riutilizzabile non \xc3\xa8 un prodotto commerciale venduto da un fornitore, ma un software open source. In questi casi, non \xc3\xa8 raro che le modifiche locali, se valide, vengano integrate nella versione ufficiale dall\'autore del componente o da una comunit\xc3\xa0 di sviluppatori volontari. In alcuni casi, gli stessi autori delle modifiche fanno parte di questa comunit\xc3\xa0 o sono autorizzati ad integrare le modifiche nella versione ufficiale del componente, cosicch\xc3\xa9 pratiche che normalmente possono portare a un vicolo cieco diventano un valido contributo a un prodotto open source._NEWLINE_Nessuna modifica \xc3\xa8, 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\xc3\xb2 essere accettabile._NEWLINE_Infine, modifiche locali a componenti riutilizzabili esterni possono essere accettabili (perch\xc3\xa9 non danno luogo ai costi e ai problemi discussi) quando l\'applicazione sviluppata \xc3\xa8 un prototipo o uno strumento di ricerca che non richiede manutenzione e aggiornamento a lungo termine.\n_START_SECTION_\nSoluzioni\n_START_PARAGRAPH_\nIl caso pi\xc3\xb9 estremo di questo anti-pattern, COTS Customization, ovvero modifiche a componenti riutilizzabili che fanno parte di prodotti commerciali, \xc3\xa8 da evitare a ogni costo._NEWLINE_Il rischio di incorrere in un vicolo cieco pu\xc3\xb2 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, \xc3\xa8 possibile che alcune delle limitazioni dei componenti siano eliminate dagli aggiornamenti._NEWLINE_Se modificare un componente riutilizzabile \xc3\xa8 una scelta obbligata, \xc3\xa8 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\xc3\xb2 essere implementato usando ad esempio il design pattern Adapter.'