Devo utilizzare un file di configurazione o un database per archiviare le regole aziendali?

Di recente ho letto The Pragmatic Programmer che afferma che:

I dettagli rovinano il nostro codice originale, specialmente se cambiano frequentemente. Ogni volta che dobbiamo entrare e cambiare il codice per adattarsi a qualche cambiamento nella logica aziendale, nella legge o nei gusti personali della direzione del giorno, corriamo il rischio di rompere il sistema, di introdurre un nuovo bug.

Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master (Posizioni Kindle 2651-2653). Pearson Education (USA). Edizione Kindle.

Attualmente sto programmando un'app Web con alcuni modelli che hanno proprietà che possono provenire solo da un insieme di valori, ad esempio (esempio non reale come dati riservati dell'app Web):

luce-> tipo = sfera / cubo / cilindro

Il tipo di luce può essere solo i tre valori precedenti, ma secondo TPP dovrei sempre codificare come se potessero cambiare e posizionare i loro valori in un file di configurazione. Poiché ci sono diversi incidenti di questo in tutta l'app, la mia domanda è:

Devo forse memorizzare valori come questi in:

• un file di configurazione:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• una singola tabella in un database con una riga per ciascun elemento di configurazione

• un database con una tabella per ogni elemento di configurazione (es tabella: light_types; colonne: id, name)

• in qualche altro modo?

Mille grazie per qualsiasi assistenza / competenza offerta.

La stessa domanda sorge nella maggior parte dei progetti a cui lavoro. Di solito, faccio questo:

1. Se è improbabile che l'insieme di valori possibili possa cambiare presto, utilizzo costanti o enumerazioni di classe / interfaccia nel codice e campi enumerabili nel database. Esempio: stato di pubblicazione dei post del blog: "non pubblicato", "sotto moderazione", "pubblicato", ecc.
2. I valori cambieranno probabilmente, ma le modifiche non influiranno sulla logica del programma - file di configurazione. Esempio: elenco di "come hai trovato il nostro sito Web?" opzioni per un elenco a discesa nel modulo di acquisto online.
3. È probabile che i valori cambino frequentemente e / o siano pensati per essere modificati da non sviluppatori, ma queste modifiche non influiranno sulla logica: un database o almeno un archivio di valori-chiave con un'interfaccia intuitiva per la modifica.
4. La modifica dei valori influirà sulla logica: probabilmente il sistema necessita di riprogettazione (spesso vera) o è necessario un motore delle regole di business. Il caso più difficile che ho visto finora è stato il costruttore di test psicologici su cui il mio collega ha lavorato. Ogni tipo di test può avere un proprio sistema di punteggio che può variare dalla semplice aggiunta a scale di caratteristiche multiple con valori positivi e negativi o persino valutazione umana delle risposte. Dopo alcune discussioni su questo progetto, abbiamo finito per usare Lua come motore di scripting, che è totalmente in conflitto con la capacità dei non sviluppatori di creare nuovi test (anche se Lua è un linguaggio relativamente semplice, non dovresti aspettarti che un non programmatore lo imparerò).

Informazioni sul preventivo di TPP. Penso che sia vero per il codice incontaminato , ma nella vita reale, è meglio iniziare in modo semplice ( principio KISS ) e aggiungere funzionalità in seguito se sono realmente necessarie ( YAGNI ).

Se i tuoi dati saranno in un database, ti consiglio di avere una tabella di "light_types" nello stesso DB. Questo ti dà la possibilità di usare chiavi esterne per imporre un vincolo che light-> type possa essere solo uno di quei valori, quindi anche se il codice incasina, i dati nel DB saranno sempre validi.

Se i dati non verranno archiviati in un DB, crearne uno solo per un mucchio di enumerazioni non farà molto bene. Potrei raccomandare un file di configurazione, se vuoi davvero evitare di codificare i valori.

(Vorrei mettere in guardia dall'andare troppo lontano per evitare l'hard-coding, tuttavia. In qualsiasi sistema non banale, ci saranno ipotesi su regole e requisiti aziendali, indipendentemente dal fatto che gli autori lo realizzino o meno. Anche se in qualche modo riesci ad evitare tutto presupposti e soft-code assolutamente tutto, in pratica si finisce con un "motore di regole", una sorta di sistema all'interno di un sistema e / o meta-linguaggio, e si ha un sacco di cose nel meta-linguaggio per attuare le regole. Non hai salvato alcun lavoro o ottenuto alcuna flessibilità; hai solo dovuto costruire e / o imparare un'altra lingua.

Ora, se vuoi trovare e utilizzare un motore di regole esistente, ciò potrebbe farti risparmiare un po 'di lavoro (oltre a rispondere alla domanda su dove archiviare gli enumeratori). Ma costruire il tuo solo raddoppia il carico di lavoro e ti porta inevitabilmente a un sistema semi-costruito da persone che davvero non sanno come costruire un motore di regole decente.)

In generale un database dovrebbe essere usato per i dati e un file di configurazione per la configurazione. (Come suggerisce il nome :) ). Mantenere la configurazione nel database è una cattiva separazione delle preoccupazioni e dovrebbe essere fatto solo se si ha un buon caso d'uso per giustificarlo.

C'è un equilibrio da raggiungere quando si decide quanta configurazione usare. Dovresti trattare i tuoi file di configurazione tanto quanto una parte di un'applicazione come il codice. Tenerlo il più conciso possibile. È molto facile per le applicazioni soffrire di gonfia configurazione in cui si finisce con un enorme file XML pieno di stringhe magiche.

Nel caso che descrivi, sarebbe ragionevole avere un elemento di configurazione per definire quale file CSS usare. (puoi quindi cambiarlo se cambiano i requisiti). Sarebbe eccessivo configurare lo stile di ciascun elemento nel file di configurazione