Informazioni di background e cosa ho provato
All'interno di ciascuno dei due ambienti per lo più distinti, ad esempio "Ricerca" e "Produzione", è necessario un file dei parametri strutturato. Il file contiene cose come connessioni al database, tabelle e altri parametri, niente di insolito.
L'approccio attuale prevede due file di parametri distinti, ad esempio "params.txt" e "params_prod.txt" (per la produzione). (Inoltre, nel caso in cui aiuti, in realtà non stiamo usando .txt per questo, stiamo usando un linguaggio di markup, ma i dettagli di ciò non contano davvero per questa domanda.)
La maggior parte delle informazioni è duplicata tra questi due file, portando a un sacco di copia / incolla. Inoltre, nel controllo della versione, ognuno deve apportare manualmente le modifiche a due file e ci si deve fidare che stiano propagando le modifiche se si verifica qualcosa.
Inutile dire che questo porta a mal di testa da risolvere quando si verificano divergenze tra i file. Abbiamo provato soluzioni alternative, come la scrittura di test per verificare che i file siano identici in tutti i modi in cui devono essere, ma questa non è una scienza perfetta poiché la struttura dei file può cambiare e la definizione di cosa, esattamente, deve essere identica tra loro cambia anche.
Ho avuto un'idea:
Basta usare un singolo file, ma creare sottosezioni all'interno del file. Ci può essere una sottosezione per i parametri generali che sono sempre condivisi, un'altra per le cose che dovrebbero essere trattate come parametri 'default' (le impostazioni dell'ambiente 'Ricerca') e poi un'altra sezione per le impostazioni dell'ambiente 'Produzione'. / p>
Abbiamo già un codice che analizza i file dei parametri e crea un'istanza di oggetti, carichi di dati, ecc. ecc., in base ai parametri. Potremmo tornare indietro e aggiungere alcune opzioni a quel codice, in modo tale che carichi i dati in base alla sottosezione del file dei parametri che viene detto di usare e ignora i parametri dall'altra sezione.
Questo ha alcuni vantaggi: (1) tutto è in un file, quindi non c'è "solo fiducia" che le persone stanno propagando le modifiche. (2) Inoltre non richiede il codice copia / incolla poiché tutto ciò che è condiviso tra entrambi gli ambienti deve apparire solo in una sezione nella parte superiore di un file di parametri. (3) Se necessario, questo dovrebbe rendere i file dei parametri stessi più modulari e più facili da usare. (4) Risparmiamo tempo / costi che sarebbero stati spesi creando complicati work-around basati sui test che controllano se i file vengono propagati insieme durante il check-in con controllo della versione. Non abbiamo bisogno di farlo in questo caso.
Ha anche dei costi: (1) tempo trascorso a fare le specifiche del file dei parametri appena formattato in XSD in modo da poterlo convalidare e assicurarsi che sia retrocompatibile; (2) costi se abbiamo bisogno di ricodificare e rendere i nostri software-that-interfaces-with-parameter-files hanno opzioni per l'uso di 'Research' o 'Production'. (3) Se una delle proprietà che sono attualmente considerate nella sottosezione condivisa, ma che improvvisamente diventano cose in cui vogliamo avere opzioni diverse tra "Ricerca" e "Produzione", dovremmo quindi rifattarci tutti i file dei parametri per spostare quell'elemento verso il basso nelle altre sezioni.
(3) Sembra la più grande preoccupazione, ma ci costringe anche a ridimensionare costantemente questi file di parametri, che è una buona cosa secondo me. Inoltre, se vogliamo flessibilità nel riassegnare un parametro da una sottosezione a un'altra, ci dovrebbero essere modi migliori per ottenerlo rispetto alla duplicazione dell'intero file.
Domanda
Ci sono delle insidie significative che non riesco a realizzare sull'idea proposta riguardo a don't-repeat-yourself rispetto ai compromessi di flessibilità nella progettazione dei file di parametri?