Permettetemi di farvi una contro-domanda completamente seria: qual è, secondo voi, la differenza tra "dati" e "codice"?
Quando sento la parola "dati", penso "stato". I dati sono, per definizione, la cosa che l'applicazione stessa è progettata per gestire, e quindi la cosa che l'applicazione non può mai conoscere al momento della compilazione. Non è possibile codificare i dati perché non appena li codifichi, diventano comportamenti, non dati.
Il tipo di dati varia in base all'applicazione; un sistema di fatturazione commerciale può archiviare informazioni su clienti e ordini in un database SQL e un programma di grafica vettoriale può archiviare dati geometrici e metadati in un file binario. In entrambi questi casi e in tutto ciò che c'è nel mezzo, c'è una chiara e indistruttibile separazione tra codice e dati. I dati appartengono all'utente , non al programmatore, quindi non possono mai essere codificati.
Quello di cui sembra parlare è usare la descrizione tecnicamente più accurata disponibile per il mio attuale vocabolario: informazioni che governano il comportamento del programma che non sono scritte nel linguaggio di programmazione principale usato per sviluppare la maggior parte dell'applicazione.
Anche questa definizione, che è considerevolmente meno ambigua della sola parola "dati", presenta alcuni problemi. Ad esempio, cosa succede se parti significative del programma sono scritte ciascuna in lingue diverse? Ho lavorato personalmente su diversi progetti che sono circa il 50% di C # e il 50% di JavaScript. Il codice JavaScript è "dati"? Molte persone direbbero di no. Che dire dell'HTML, sono "dati"? Molte persone direbbero ancora di no.
E i CSS? Sono dati o codice? Se pensiamo al codice come qualcosa che controlla il comportamento del programma, allora il CSS non è in realtà un codice, perché influenza solo (bene, principalmente) l'aspetto, non il comportamento. Ma non sono nemmeno dei dati; l'utente non lo possiede, l'applicazione non lo possiede nemmeno. È l'equivalente del codice per un designer dell'interfaccia utente. È simile al codice, ma non del tutto.
Potrei chiamare CSS un tipo di configurazione, ma una definizione più pratica è che si tratta semplicemente di un codice in un linguaggio specifico del dominio . Questo è ciò che spesso rappresentano XML, YAML e altri "file formattati". E la ragione per cui usiamo un linguaggio specifico del dominio è che, in generale, è simultaneamente più conciso ed espressivo nel suo particolare dominio rispetto alla codifica delle stesse informazioni in un linguaggio di programmazione generico come C o C # o Java.
Riconosci il seguente formato?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Sono sicuro che molte persone lo fanno; è JSON . Ed ecco la cosa interessante di JSON: in JavaScript, è chiaramente un codice, e in ogni altra lingua, sono dati chiaramente formattati. Quasi ogni singolo linguaggio di programmazione tradizionale ha almeno una libreria per "analizzare" JSON.
Se utilizziamo la stessa identica sintassi all'interno di una funzione in un file JavaScript, non può essere altro che un codice. Eppure, se prendiamo quel JSON, lo inseriamo in un .jsonfile e lo analizziamo in un'applicazione Java, improvvisamente sono "dati". Ha davvero senso?
Io sostengo che "data-ness" o "configuration-ness" o "code-ness" è inerente a ciò che viene descritto, non al modo in cui viene descritto.
Se il tuo programma ha bisogno di un dizionario di 1 milione di parole per, per esempio, generare una passphrase casuale, vuoi codificarla in questo modo:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
O semplicemente spingeresti tutte quelle parole in un file di testo delimitato da righe e diresti al tuo programma di leggere da esso? Non importa se l'elenco di parole non cambia mai, non è una questione di codifica hard o soft-coding (che molti considerano giustamente un anti-pattern se applicato in modo inappropriato), è semplicemente una questione di quale formato è più efficiente e semplifica la descrizione delle "cose", qualunque esse siano. È abbastanza irrilevante se lo chiami codice o dati; sono le informazioni che il tuo programma richiede per funzionare, e un formato di file flat è il modo più conveniente per gestirlo e mantenerlo.
Supponendo che tu segua le pratiche appropriate, tutte queste cose andranno comunque al controllo del codice sorgente, quindi potresti anche chiamarlo codice, solo codice in un formato diverso e forse molto minimalista. Oppure puoi chiamarlo configurazione, ma l'unica cosa che distingue veramente il codice dalla configurazione è se lo documenti e dici agli utenti finali come modificarlo. Potresti forse inventare qualche argomento falso sulla configurazione interpretata in fase di avvio o di runtime e non in fase di compilazione, ma poi inizieresti a descrivere diversi linguaggi tipizzati dinamicamente e quasi sicuramente qualsiasi cosa con un motore di scripting incorporato al suo interno (ad es. la maggior parte dei giochi). Codice e configurazione sono qualunque cosa tu decida di etichettarli come, niente di più, niente di meno.
Ora, non v'è un pericolo per esternalizzare le informazioni che in realtà non è sicura di modificare (si veda il link "soft codifica" di cui sopra). Se estrai l'array di vocali in un file di configurazione e lo documenti come file di configurazione per gli utenti finali, stai offrendo loro un modo quasi infallibile per rompere istantaneamente la tua app, ad esempio inserendo "q" come vocale. Ma questo non è un problema fondamentale con la "separazione di codice e dati", è semplicemente un cattivo senso del design.
Quello che dico agli sviluppatori junior è che dovrebbero sempre esternalizzare le impostazioni che si aspettano di cambiare per ambiente. Ciò include elementi quali stringhe di connessione, nomi utente, chiavi API, percorsi di directory e così via. Essi potrebbero essere gli stessi sulla propria macchina dev e in produzione, ma probabilmente non, e gli amministratori di sistema potranno decidere come vogliono farlo sembrare in produzione, non gli sviluppatori. Quindi hai bisogno di un modo per avere un gruppo di impostazioni applicate su alcune macchine e altre impostazioni applicate su altre macchine - ergo, file di configurazione esterni (o impostazioni in un database, ecc.)
Ma sottolineo che semplicemente inserire alcuni "dati" in un "file" non equivale a esternalizzarli come configurazione. Mettere un dizionario di parole in un file di testo non significa che vuoi che gli utenti (o IT) lo cambino, è solo un modo per rendere molto più facile per gli sviluppatori capire cosa diavolo sta succedendo e, se necessario, fare cambiamenti occasionali. Allo stesso modo, inserire le stesse informazioni in una tabella di database non conta necessariamente come esternalizzazione del comportamento, se la tabella è di sola lettura e / o ai DBA viene chiesto di non rovinarsene. La configurazione implica che i dati sono mutabili, ma in realtà ciò è determinato dal processo e dalle responsabilità piuttosto che dalla scelta del formato.
Quindi, per riassumere:
"Codice" non è un termine rigidamente definito. Se estendi la tua definizione per includere linguaggi specifici del dominio e qualsiasi altra cosa che influenzi il comportamento, gran parte di questo apparente attrito semplicemente scomparirà e tutto avrà un senso. Puoi avere un "codice" DSL non compilato in un file flat.
"Dati" implica informazioni di proprietà dell'utente (i) o almeno di un soggetto diverso dagli sviluppatori e generalmente non disponibili in fase di progettazione. Non potrebbe essere hardcoded anche se si desidera farlo. Con la possibile eccezione del codice automodificante , la separazione tra codice e dati è una questione di definizione, non di preferenza personale.
Il "soft-coding" può essere una pratica terribile se applicato in modo eccessivo, ma non tutte le istanze di esternalizzazione costituiscono necessariamente un soft-coding e molti casi di memorizzazione di informazioni in "file flat" non sono necessariamente un tentativo in buona fede di esternalizzazione.
La configurazione è un tipo speciale di soft-coding che è necessario a causa della conoscenza che potrebbe essere necessario eseguire l'applicazione in ambienti diversi. La distribuzione di un file di configurazione separato insieme all'applicazione richiede molto meno lavoro (e molto meno pericoloso) rispetto alla distribuzione di una versione diversa del codice in ogni ambiente. Quindi alcuni tipi di soft-coding sono effettivamente utili.