Lassen Sie mich Ihnen eine ganz ernste Gegenfrage stellen: Was ist aus Ihrer Sicht der Unterschied zwischen "Daten" und "Code"?
Wenn ich das Wort "data" höre, denke ich "state". Daten sind per Definition das, wofür die Anwendung selbst entwickelt wurde, und daher genau das, was die Anwendung zur Kompilierungszeit niemals wissen kann. Es ist nicht möglich , Daten fest zu codieren, da sie, sobald Sie sie fest codieren, zu Verhalten werden und nicht zu Daten.
Die Art der Daten variiert je nach Anwendung. Ein kommerzielles Fakturierungssystem kann Kunden- und Bestellinformationen in einer SQL-Datenbank speichern, und ein Vektorgrafikprogramm kann Geometriedaten und Metadaten in einer Binärdatei speichern. In beiden Fällen und in allen dazwischen liegenden Fällen besteht eine klare und unzerbrechliche Trennung zwischen Code und Daten. Die Daten gehören dem Benutzer und nicht dem Programmierer, so dass sie niemals fest codiert werden können.
Was Sie zu reden scheinen, ist, die technisch genaueste Beschreibung zu verwenden, die meinem aktuellen Wortschatz zur Verfügung steht: Informationen über das Programmverhalten, die nicht in der primären Programmiersprache geschrieben sind, die zur Entwicklung des Großteils der Anwendung verwendet wurde.
Auch diese Definition, die deutlich weniger mehrdeutig ist als nur das Wort "Daten", weist einige Probleme auf. Was ist zum Beispiel, wenn wesentliche Teile des Programms in verschiedenen Sprachen geschrieben sind? Ich habe persönlich an mehreren Projekten mit etwa 50% C # und 50% JavaScript gearbeitet. Ist der JavaScript-Code "Daten"? Die meisten Leute würden nein sagen. Was ist mit HTML? Sind das "Daten"? Die meisten Leute würden immer noch nein sagen.
Was ist mit CSS? Sind das Daten oder Code? Wenn wir uns Code als etwas vorstellen, das das Programmverhalten steuert, dann ist CSS nicht wirklich Code, da es nur (nun ja, meistens) das Erscheinungsbild beeinflusst, nicht das Verhalten. Aber es sind auch keine wirklichen Daten; der Benutzer besitzt es nicht, die Anwendung besitzt es nicht einmal wirklich. Dies entspricht dem Code eines UI-Designers. Es ist Code- ähnlich , aber nicht ganz Code.
Ich könnte CSS als eine Art Konfiguration bezeichnen, aber eine praktischere Definition ist, dass es sich einfach um Code in einer domänenspezifischen Sprache handelt . Das ist es, was Ihre XML-, YAML- und anderen "formatierten Dateien" oft darstellen. Der Grund, warum wir eine domänenspezifische Sprache verwenden, ist, dass sie in der Regel in ihrer jeweiligen Domäne präziser und aussagekräftiger ist als die Codierung derselben Informationen in einer universellen Programmiersprache wie C oder C # oder Java.
Erkennen Sie das folgende Format?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Ich bin sicher, dass die meisten Leute das tun. Es ist JSON . Und hier ist das Interessante an JSON: In JavaScript ist es klarer Code und in jeder anderen Sprache sind es klar formatierte Daten. Fast jede Mainstream-Programmiersprache verfügt über mindestens eine Bibliothek zum "Parsen" von JSON.
Wenn wir genau dieselbe Syntax in einer Funktion in einer JavaScript-Datei verwenden, kann es möglicherweise nichts anderes als Code sein. Und doch, wenn wir diesen JSON nehmen, ihn in eine .jsonDatei schieben und in einer Java-Anwendung analysieren, sind es plötzlich "Daten". Ist das wirklich sinnvoll?
Ich behaupte, dass die "Daten-Ness" oder "Konfigurations-Ness" oder "Code-Ness" dem innewohnt, was beschrieben wird, und nicht, wie es beschrieben wird.
Wenn Ihr Programm ein Wörterbuch mit 1 Million Wörtern benötigt, um beispielsweise eine zufällige Passphrase zu generieren, möchten Sie sie folgendermaßen codieren:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
Oder würden Sie einfach alle diese Wörter in eine durch Zeilen getrennte Textdatei schieben und Ihrem Programm anweisen, daraus zu lesen? Es spielt keine Rolle, ob sich die Wortliste nie ändert, es geht nicht darum, ob Sie hart oder weich codieren (was zu Recht von vielen als Antimuster angesehen wird, wenn es nicht richtig angewendet wird), es geht einfach darum, Welches Format ist am effizientesten und macht es am einfachsten, das "Zeug" zu beschreiben, was auch immer das "Zeug" ist. Es ist ziemlich irrelevant, ob Sie es Code oder Daten nennen; Es sind Informationen, die Ihr Programm benötigt, um ausgeführt zu werden, und ein Flat-File-Format ist die bequemste Methode, um es zu verwalten und zu warten.
Vorausgesetzt, Sie befolgen die richtigen Vorgehensweisen, wird all dieses Zeug sowieso in die Quellcodeverwaltung verschoben. Sie können es also genauso gut als Code bezeichnen, nur als Code in einem anderen und vielleicht sehr minimalistischen Format. Sie können es auch Konfiguration nennen, aber das einzige, was Code wirklich von Konfiguration unterscheidet, ist, ob Sie es dokumentieren und den Endbenutzern mitteilen, wie sie es ändern sollen oder nicht. Sie könnten sich vielleicht ein falsches Argument über die Interpretation der Konfiguration zum Startzeitpunkt oder zur Laufzeit und nicht zur Kompilierungszeit ausdenken, aber dann würden Sie damit beginnen, mehrere dynamisch typisierte Sprachen und mit ziemlicher Sicherheit alles mit einer darin eingebetteten Skript-Engine zu beschreiben (z. B. die meisten Spiele). Code und Konfiguration bestimmen Sie, ob Sie sie als, nicht mehr, nicht weniger, bezeichnen möchten.
Jetzt besteht die Gefahr, dass Informationen, deren Änderung nicht sicher ist, nach außen verlagert werden (siehe Link "Soft Coding" oben). Wenn Sie Ihr Vokalarray in einer Konfigurationsdatei externalisieren und es als Konfigurationsdatei für Ihre Endbenutzer dokumentieren, bieten Sie ihnen eine nahezu kinderleichte Möglichkeit, Ihre App sofort zu unterbrechen, indem Sie beispielsweise "q" als Vokal eingeben. Aber das ist kein grundsätzliches Problem bei der "Trennung von Code und Daten", es ist einfach ein schlechter Gestaltungssinn.
Was ich Junior-Entwicklern sage, ist, dass sie immer Einstellungen externalisieren sollten, die sich erwartungsgemäß pro Umgebung ändern. Dazu gehören beispielsweise Verbindungszeichenfolgen, Benutzernamen, API-Schlüssel, Verzeichnispfade usw. Sie können auf Ihrer Entwickler-Box und in der Produktion identisch sein, aber wahrscheinlich auch nicht. Die Systemadministratoren entscheiden, wie es in der Produktion aussehen soll, nicht die Entwickler. Sie müssen also die Möglichkeit haben, eine Gruppe von Einstellungen auf einige Maschinen und andere Einstellungen auf andere Maschinen anzuwenden - also externe Konfigurationsdateien (oder Einstellungen in einer Datenbank usw.).
Ich betone jedoch, dass es nicht gleichbedeutend ist, einige "Daten" in eine "Datei" einzufügen, wenn man sie als Konfiguration auslagert. Das Einfügen eines Wörterbuchs in eine Textdatei bedeutet nicht, dass Sie möchten, dass Benutzer (oder IT-Abteilung) es ändern. Es ist nur eine Möglichkeit, Entwicklern das Verstehen der Vorgänge zu erleichtern und erforderlichenfalls Änderungen vorzunehmen gelegentliche Änderungen. Ebenso gilt das Speichern derselben Informationen in einer Datenbanktabelle nicht unbedingt als Externalisierung des Verhaltens, wenn die Tabelle schreibgeschützt ist und / oder Datenbankadministratoren angewiesen werden, sich niemals damit zu beschäftigen. Die Konfiguration impliziert, dass die Daten veränderlich sind, in Wirklichkeit jedoch eher durch den Prozess und die Verantwortlichkeiten als durch die Wahl des Formats bestimmt werden.
Also, um zusammenzufassen:
"Code" ist kein fest definierter Begriff. Wenn Sie Ihre Definition um domänenspezifische Sprachen und alles andere erweitern, was das Verhalten beeinflusst, wird ein Großteil dieser offensichtlichen Reibung einfach verschwinden und alles wird Sinn machen. Sie können nicht kompilierten DSL- "Code" in einer Flatfile haben.
"Daten" implizieren Informationen, die den Benutzern oder zumindest einer anderen Person als den Entwicklern gehören und zur Entwurfszeit nicht allgemein verfügbar sind. Es könnte nicht hartcodiert werden, selbst wenn Sie dies wollten. Mit der möglichen Ausnahme von selbstmodifizierendem Code ist die Trennung zwischen Code und Daten eine Definitionssache und keine persönliche Präferenz.
"Soft-Codierung" kann eine schreckliche Praxis sein, wenn sie übermäßig angewendet wird, aber nicht jeder Fall von Externalisierung stellt notwendigerweise eine Soft-Codierung dar, und viele Fälle des Speicherns von Informationen in "flachen Dateien" sind nicht notwendigerweise ein ernsthafter Versuch der Externalisierung.
Die Konfiguration ist eine spezielle Art der Softcodierung, die aufgrund der Kenntnisse erforderlich ist , die die Anwendung möglicherweise in verschiedenen Umgebungen ausführen muss. Das Bereitstellen einer separaten Konfigurationsdatei zusammen mit der Anwendung ist weitaus weniger arbeitsaufwendig (und auch weniger gefährlich) als das Bereitstellen einer anderen Version des Codes in jeder Umgebung. So einige Arten von Soft-Codierung ist wirklich nützlich.