Best practice per la compatibilità legacy [chiuso]

Question

Dalla mia esperienza, gli impegni per la compatibilità con le versioni precedenti sono la gabbia dorata della industria dell'ingegneria del software. Ho osservato in particolare che questo è il caso dei formati di file di documenti e dei linguaggi di programmazione / API. Clienti e partner lo odiano quando i loro dati o codice esistenti si rompono; tuttavia, se non rompi mai la compatibilità, puoi limitare seriamente la tua capacità di innovare nel lungo periodo.

Esistono soluzioni a questo problema, oltre alla graduale deprecazione delle vecchie funzionalità? Sembra che la virtualizzazione, come nella modalità XP di Windows 7, sia una possibilità entusiasmante. Ce ne sono altri?

Inoltre, per quelli di noi che vogliono progettare nuovi sistemi il più a prova di futuro possibile, quali lezioni possiamo imparare dagli errori passati commessi nel settore?

Answer 1

Innovare estendendo, non riscrivendo le API pubbliche. Avere interfacce pubbliche generiche coerenti con funzionalità back-end. È possibile riscrivere i moduli privati ??in qualsiasi momento, purché si forniscano ai moduli API pubblici i risultati previsti.

Apporta i tuoi miglioramenti al back-end e lascia l'API coerente il più possibile. Crea nuovi moduli e documentali chiaramente quando estendi le parti pubbliche della tua API, il deprezzamento dei vecchi modi arriverà naturalmente se fornisci modi nuovi e migliori per fare cose che si aggiungono ai vecchi metodi.

Per i formati di documento, includere sempre i numeri di versione e assicurarsi di disporre di modi per supportare tutte le versioni esistenti. Come per le API, aggiungi la nuova funzionalità estendendola, non riscrivendola.

Quando vuoi apportare cambiamenti fondamentali all'architettura generale del tuo software, fai in modo che la nuova versione includa quella vecchia come modulo - porterà a dimensioni maggiori ma a un supporto migliore per dati e programmi meno recenti.

Answer 2

Usa XML come base per il tuo formato di file e aggiungi solo al DTD della specifica, non eliminare. In questo modo i tuoi file dovrebbero essere retrocompatibili con le versioni precedenti, il che è un vantaggio.

Answer 3

Ecco un buon esempio: usare SLF4J Bridges per consentire una facile migrazione da un modulo di registrazione a un altro in Java.