I file di configurazione esterni sono considerati antipattern?

La maggior parte delle applicazioni richiede alcune configurazioni esterne; puoi nasconderlo rendendolo dipendente da variabili magiche o salvandolo in una posizione interna, ma ciò non eliminerà la necessità. L'obiettivo è riconoscere ciò che dovrebbe essere esterno e ciò che può essere interno. Solo le parti interne possono essere testate.

Un'applicazione non dovrebbe considerare attendibile un file di configurazione esterno. Dovrebbe controllare la correttezza e riportare errori. Se non è possibile per l'applicazione controllare il file di configurazione, probabilmente stai facendo troppo con esso. Se il file di configurazione cambia il comportamento dell'applicazione, non dovrebbe essere esterno a mio parere.

Ad esempio, un nome utente / password del database possono essere facilmente verificati dall'applicazione cercando di connettersi al database. Se questo non riesce, può segnalarlo, e ovviamente non è un bug nel codice dell'applicazione. Allo stesso modo, per un percorso di file è possibile verificare l'esistenza e i diritti di accesso.

Ora, se dovessi inserire query SQL nel file di configurazione, l'applicazione non può facilmente verificare la correttezza di tali query. Lo stesso vale per una specifica di iniezione a dipendenza completa (un file XML Java-Spring). Quelli non dovrebbero essere in file di configurazione esterni.

Ma se la configurazione specificata descrive qualcosa di esterno e puoi verificarne rapidamente la correttezza, non penso che ci sia qualcosa di sbagliato nei file di configurazione esterni.

Modifica: assicurati anche che i tuoi rapporti di errore mostrino quale file di configurazione viene utilizzato. Niente è più frustrante che scoprire che stavi guardando il file sbagliato dopo ore di tentativi di scoprire cosa c'è che non va.

Le classificherei più come "area problematica nota" che come antipattern. A meno che non si disponga di una configurazione fissa, è necessario memorizzare le informazioni di configurazione da qualche parte . Solitamente mi piace memorizzare la maggior parte delle informazioni di configurazione nel database, ma è comunque necessario memorizzare le informazioni di connessione del database da qualche parte. Preferisco l'approccio Java / Spring di archiviare le informazioni di configurazione nella struttura dell'applicazione stessa, piuttosto che (diciamo) nella home directory dell'utente o nel registro di Windows, ma questa è solo una preferenza personale.

I file di configurazione esterni NON sono anti-pattern. Come tutto il resto, possono essere utilizzati bene o male a seconda del sistema in questione.

Sembra che tu abbia incontrato alcune app in cui la configurazione esterna può interrompere l'app senza dire all'utente cosa sta succedendo. Non va bene, ma non è colpa dei file di configurazione, è colpa di chi ha deciso quali parti sono nei file di configurazione e quali parti sono nell'app e come gestire gli errori tra di loro.

A mio parere: NO , i file di configurazione esterni non sono un antipattern.

È solo a technique un modello architettonico per gestire la complessità del software.

Nell'era dei principi di progettazione SOLID hai spostato la complessità del software da Monolithic_application a più moduli indipendenti che devono essere collegati insieme.

l'alternativa ai "file di configurazione esterni" sarebbe quella di configurare i moduli direttamente dal codice.

Se possibile, è preferibile spostare la configurazione dalla logica ai dati. Ti permette di rendere l'applicazione più flessibile senza la necessità di rielaborare il tuo codice. I file di dati mancanti sono più un caso di documentazione insufficiente o di lavoro sciatto durante l'installazione rispetto a una cattiva pratica in termini di codifica IMHO.

Fai in modo che lo strumento SCM preferito funzioni come strumento CM: inserisci i file di configurazione nel repository. Per cambiare la configurazione, commetti le modifiche e consenti ai tuoi strumenti di distribuzione automatica di inviarle alla produzione (dopo aver eseguito una serie di test automatizzati, ovviamente!)

Et Voila! hai una registrazione di tutte le modifiche alla configurazione, oltre alla rete di sicurezza aggiuntiva di un sistema CI / test automatico!

Come è stato sottolineato prima, architettura e amp; i modelli di progettazione non si limitano al sistema stesso del prodotto, ma si estendono anche al team / processo / ai sistemi che aiutano a produrlo.