Come si separa in modo pulito il codice per la compatibilità con le versioni precedenti dal codice principale?

Question

Sono interessato a quali strategie le persone hanno escogitato per separare tutta la logica crufty necessaria per mantenere la retrocompatibilità dal codice principale di un'applicazione. In altre parole, strategie che ti consentono di avvicinarti ad avere il tuo codice come se non ci fossero problemi di compatibilità con le versioni precedenti, ad eccezione di file sorgente separati separati distintamente per quell'attività.

Ad esempio, se l'applicazione legge un particolare formato di file, invece di una gigantesca funzione di analisi dei suoni, è possibile che il codice esegua prima una iterazione di un elenco di voci/oggetti "quirk", in cui ogni stranezza controlla il file per vedere se è un file a cui si applica, e in tal caso invoca la propria logica di analisi anziché la normale logica del caso.

Quirks è una strategia OK, ma devi lavorare per mettere i ganci per i controlli di quirk in tutti i punti appropriati della tua app, e come saranno i controlli per vari tipi di eccentricità, ecc. Sembra quasi come dovrebbero esserci librerie dedicate al boilerplate per questo compito. Un altro problema è come far sì che le stranezze non vengano abusate come aggancio generale in blocchi arbitrari dell'app.

Answer 1

La mia strategia abituale è di avere qualcosa di separato che tradurrà l'input di compatibilità con le versioni precedenti nel nuovo input di implementazione e quindi utilizzare il nuovo codice di implementazione con questi dati tradotti.

Answer 2

Ciò dipenderà dal periodo di tempo fino al ritiro di dette caratteristiche di compatibilità all'indietro. Sei abbastanza sicuro che tra un paio di mesi rilascerai un'altra versione del tuo software che non dovrà più avere quei capricci, puoi semplicemente mantenere il vecchio codice se sei abbastanza disciplinato da rimuovere effettivamente tutto il cruft nel prossimo ciclo di sviluppo. Sto mantenendo due componenti separati del server di back-end dove lavoro e mentre non possono essere aggiornati allo stesso tempo, di solito possono trovarsi entro un paio di settimane l'uno dall'altro. Ciò significa che la comunicazione tra di loro deve essere retrocompatibile, ma solo una versione posteriore, e in ogni versione posso rimuovere il vecchio codice che ho lasciato per ragioni di compatibilità all'indietro nella versione precedente.

Se il livello di compatibilità è lì per rimanere a lungo o addirittura indefinitamente (si pensi ai formati di file binari di Word), proverei a rifattorizzare il codice in modo tale che la nuova funzionalità e le vecchie funzionalità siano uguali termini in esso. Penso che sia il vecchio formato (o comportamento) sia il nuovo formato fanno parte dei requisiti del sistema e non c'è motivo per il vecchio formato di essere un cittadino di seconda classe (oltre ad essere vecchio, è un gioco di parole).