Quali valori in un'applicazione dovrebbero essere configurabili?

Ci sono due estremi:

1. Indica tutto il codice. Questo ha il vantaggio di essere semplice ed evita il sovraccarico della configurazione. Gli svantaggi sono ovvi: manutenibilità, modifiche alla configurazione hot-deploy, impostazioni variabili in ambienti diversi, ecc.
2. Imposta tutto su un'impostazione di configurazione. Questo ha la massima flessibilità al costo di avere file di configurazione di grandi dimensioni con impostazioni che raramente e talvolta non cambiano mai.

È difficile avere una linea guida perché varia da caso a caso.

Alcune domande per chiedere ogni impostazione:

• Quanto è probabile che cambi questo? Più probabilmente suggerisce config, meno probabile che una costante di codice possa essere accettabile.
• Se cambia, abbiamo bisogno di risultati immediati o possiamo aspettare una piena compilazione e ridistribuzione? Se una ricostruzione e la distribuzione sono accettabili, allora una costante di codice può essere accettabile.
• Il valore dovrebbe mai essere diverso tra diversi ambienti? Se è così, ovviamente non puoi inserirlo nel tuo codice a meno che il tuo codice non sia a conoscenza degli ambienti, il che non è una grande idea nella mia mente.
• Il valore è dettato da una regola aziendale? Ad esempio, è probabile che le dimensioni della pagina quando si impagina un elenco vengano specificate da una specifica dei requisiti. Se lo è, allora la necessità di vedere una modifica abbia effetto immediato è probabilmente inesistente. È probabile che il cambiamento venga monitorato tramite il controllo della modifica dei requisiti del prodotto e quindi l'incorporazione del valore nel codice è probabilmente saggia.
• Se l'impostazione è correlata alle prestazioni, è probabile che sia disponibile per l'hot / field, quindi la configurazione è la strada da percorrere.

Quando consiglio di memorizzare le impostazioni nel codice, presumo che utilizzi una costante centralizzata e non un codice fisso in ogni posizione che lo utilizza.

Condividerò una divertente storia di cattivo uso costante che mi ricorda. Ho visto il codice in cui è passata una costante per le dimensioni della pagina. La costante è denominata HUNDRED_STRING. HUNDRED_STRING è ovviamente impostato su "100". Non vedo l'ora di vedere cosa succede quando qualcuno imposta HUNDRED_STRING="200" e il mondo impazzisce.

Ovviamente, più il valore dovrebbe essere modificato, più è probabile che crei un'impostazione di configurazione piuttosto che codificarlo. Generalmente ho una regola dei tre colpi; Effettua prima un hard-code perché è facile, quindi cambialo una volta sulla prima richiesta utente, e dopo la modifica successiva, rifattalo in un valore di configurazione che può essere modificato sul posto senza un altro aggiornamento del codice.

Altri fattori che mi porteranno verso l'hard-coding:

• Il valore è un dettaglio di implementazione. Se ai tuoi utenti finali non interessa il suo valore, non esporlo.
• Il valore è una "costante universale" per il sistema; forse non è qualcosa di matematico come pi o e , ma un valore che, se mai ha modificato, richiederebbe comunque modifiche sostanziali al codice.
• Il programma non usa impostazioni di configurazione condivise, ed è più facile / più sicuro inviare un aggiornamento completo piuttosto che fare in modo che gli utenti aggiornino le loro configurazioni locali. Ho un paio di app ClickOnce a cui è difficile accedere nel filesystem in base alla progettazione, mentre una pubblicazione e un aggiornamento sono relativamente facili. In queste circostanze, l'utilizzo delle impostazioni di configurazione per i valori indipendenti dalla macchina è a mio vantaggio di coder.

Fattori che mi portano verso le impostazioni di configurazione (sia in un file locale che in un DB condiviso):

• Uptime è fondamentale. I servizi aziendali critici che possono essere disattivati per la manutenzione solo nelle ore notturne o nei fine settimana non lavorative dovrebbero essere progettati con pochi motivi per eseguire tale manutenzione il più possibile. Quindi, non solo dovresti rendere i valori di controllo che potrebbero cambiare indipendentemente da altri codici in valori di configurazione, il servizio dovrebbe essere progettato per aggiornare questi valori e modificare la sua configurazione periodicamente, così non hai nemmeno bisogno di un riavvio manuale.
• Il valore varia tra le installazioni. Il numero di telefono della workstation su cui è installato il software è un ovvio esempio di qualcosa che non è mai OK per l'hard-code.
• Il valore fa parte di un sistema progettato per essere personalizzabile. Ad esempio, i programmi con più finestre figlio come una MDI dovrebbero ricordare le posizioni dei diversi tipi di finestre quando sono chiuse e riaprire il successivo di quel tipo nello stesso punto. Questo potrebbe non essere configurabile dall'utente, ma non solo hard-code a meno che gli utenti non siano addestrati specificamente verso un particolare layout.