wake-up-neo.com

Ab wann wird eine Konfigurationsdatei zur Programmiersprache?

Ich habe eine Weile über Konfigurationsdateien und ihre Beziehung zum Code nachgedacht und je nach Tag und Windrichtung scheinen sich meine Meinungen zu ändern. Obwohl ich immer wieder zu der Erkenntnis zurückkehre, die ich zum ersten Mal beim Lernen von LISP hatte: Es gibt kaum einen Unterschied zwischen Daten und Code. Dies scheint in doppelter Hinsicht für Konfigurationsdateien zu gelten. Im richtigen Licht betrachtet ist ein Perl-Skript kaum mehr als eine Konfigurationsdatei für Perl. Dies hat in der Regel schwerwiegende Konsequenzen für Aufgaben wie Qualitätssicherung und Arbeitsteilung, z. B. wer für das Ändern von Konfigurationsdateien verantwortlich sein sollte.

Der Übergang von der Konfigurationsdatei zur vollwertigen Sprache ist im Allgemeinen langsam und scheint vom Wunsch nach einem generischen System getrieben zu sein. Die meisten Projekte scheinen klein anzufangen, mit ein paar Konfigurationselementen wie dem Ort, an dem Protokolle geschrieben, nach Daten, Benutzernamen und Kennwörtern gesucht werden usw. Aber dann beginnen sie zu wachsen: Funktionen können nun aktiviert oder deaktiviert werden. Die Zeitabläufe und die Reihenfolge der Operationen werden gesteuert, und es ist unvermeidlich, dass jemand damit beginnen möchte, Logik hinzuzufügen (z. B. 10 verwenden, wenn die Maschine X ist, und 15, wenn die Maschine Y ist). Ab einem bestimmten Punkt wird die Konfigurationsdatei zu einer domänenspezifischen Sprache und zu einer schlecht geschriebenen.

Nachdem ich mich auf den Weg gemacht habe, um die Bühne zu bereiten, sind hier meine Fragen:

  1. Was ist der wahre Zweck einer Konfigurationsdatei?
  2. Sollte versucht werden, die Konfigurationsdateien einfach zu halten?
  3. Wer sollte dafür verantwortlich sein, Änderungen vorzunehmen (Entwickler, Benutzer, Administratoren usw.)?
  4. Sollten sie quellengesteuert sein (siehe Frage 3)?

Wie ich bereits sagte, ändern sich meine Antworten auf diese Fragen ständig, aber ich denke gerade:

  1. einem Nicht-Programmierer zu ermöglichen, große Verhaltensteile schnell zu ändern
  2. ja, alles, was nicht grobkörnig ist, sollte im Code sein
  3. benutzer sollten für Konfigurationsdateien verantwortlich sein, und Programmierer sollten für eine Konfigurationsebene zwischen Konfigurationsdateien und Code verantwortlich sein, die eine genauere Steuerung der Anwendung ermöglicht
  4. nein, aber die feinkörnigere Mittelschicht sollte sein
86
Chas. Owens

Sehr interessante Fragen!

Ich neige dazu, meine Konfigurationsdateien auf ein sehr einfaches "key = value" -Format zu beschränken, da ich Ihnen voll und ganz zustimme, dass Konfigurationsdateien sehr schnell zu vollwertigen Programmen werden können. Zum Beispiel kennt jeder, der jemals versucht hat, OpenSER zu "konfigurieren", das Gefühl, von dem Sie sprechen: Es ist keine Konfiguration, es ist (schmerzhafte) Programmierung.

Wenn Sie möchten, dass Ihre Anwendung auf eine Art und Weise "konfigurierbar" ist, die Sie sich heute nicht vorstellen können, dann brauchen Sie wirklich ein Plugins-System. Sie müssen Ihre Anwendung so entwickeln, dass eine andere Person ein neues Plugin codieren und es in Zukunft in Ihre Anwendung einbinden kann.

So beantworten Sie Ihre Fragen:

  1. Was ist der wahre Zweck einer Konfigurationsdatei?

    Ich würde sagen, damit die Benutzer, die Ihre Anwendung installieren, einige bereitstellungsbezogene Parameter wie den Hostnamen, die Anzahl der Threads, die Namen der benötigten Plugins und die Bereitstellungsparameter für diese Plugins abrufen können (aktivieren Sie diese Option) Schauen Sie sich die FreeRadius-Konfiguration für ein Beispiel dieses Prinzips an. Auf keinen Fall der Ort, um Geschäftslogik auszudrücken.

  2. Sollte versucht werden, die Konfigurationsdateien einfach zu halten?

    Bestimmt. Wie Sie vorgeschlagen haben, ist "Programmieren" in einer Konfigurationsdatei schrecklich. Ich glaube, das sollte vermieden werden.

  3. Wer sollte dafür verantwortlich sein, Änderungen vorzunehmen (Entwickler, Benutzer, Administratoren usw.)?

    Im Allgemeinen würde ich Administratoren sagen, die die Anwendung bereitstellen.

  4. Sollten sie quellengesteuert sein (siehe Frage 3)?

    Normalerweise werden die Konfigurationsdateien nicht von mir selbst in der Quellcodeverwaltung verwaltet, aber ich verwende eine Vorlagenkonfigurationsdatei mit allen Parametern und ihren Standardwerten sowie Kommentaren, die beschreiben, was sie enthalten tun. Wenn eine Konfigurationsdatei beispielsweise den Namen database.conf trägt, verwalte ich normalerweise eine Quellcodeverwaltung mit dem Namen database.conf.template. Jetzt spreche ich natürlich darüber, was ich als Entwickler mache . Als Administrator möchte ich möglicherweise die tatsächlichen Einstellungen, die ich für jede Installation ausgewählt habe, als Quellcode steuern. Zum Beispiel verwalten wir ein paar hundert Server remote und müssen ihre Konfigurationen nachverfolgen: Wir haben uns dafür entschieden, dies mit der Quellcodeverwaltung zu tun.


Edit : Obwohl ich glaube, dass das oben Gesagte für die meisten Anwendungen zutrifft, gibt es natürlich immer Ausnahmen. In Ihrer Anwendung können Benutzer beispielsweise komplexe Regeln dynamisch konfigurieren. Bei den meisten E-Mail-Clients können die Benutzer Regeln für die Verwaltung ihrer E-Mails definieren (z. B. "Alle E-Mails, die von" John Doe "stammen und mich nicht im Feld" An "haben, sollten verworfen werden"). Ein weiteres Beispiel ist eine Anwendung, mit der der Benutzer ein neues komplexes kommerzielles Angebot definieren kann. Sie können auch an Anwendungen wie Cognos denken, mit denen Benutzer komplexe Datenbankberichte erstellen können. Der E-Mail-Client bietet dem Benutzer wahrscheinlich eine einfache Schnittstelle zum Definieren der Regeln. Dadurch wird eine komplexe Konfigurationsdatei (oder sogar ein bisschen Code) generiert. Andererseits kann die benutzerdefinierte Konfiguration für die kommerziellen Angebote auf strukturierte Weise in einer Datenbank gespeichert werden (weder eine einfache Struktur aus Schlüssel und Wert noch ein Teil des Codes). In einigen anderen Anwendungen kann der Benutzer möglicherweise sogar python oder VB oder eine andere automatisierungsfähige Sprache verwenden. Mit anderen Worten ... Ihr Kilometerstand kann variieren.

38
MiniQuark

OK. Sie werden einige Benutzer haben, die eine wirklich einfache Konfiguration wünschen, die Sie ihnen geben sollten. Zur gleichen Zeit werden Sie ständig gefragt "Kannst du das hinzufügen? Wie mache ich das in der Konfigurationsdatei?". Ich verstehe nicht, warum Sie nicht beide Gruppen unterstützen können.

Das Projekt, an dem ich gerade arbeite, verwendet Lua für seine Konfigurationsdatei. Lua ist eine Skriptsprache und funktioniert in diesem Szenario gut. Es gibt ein Beispiel für unsere Standardkonfiguration .

Sie werden feststellen, dass es sich hauptsächlich um Anweisungen mit Schlüssel = Wert handelt, wobei der Wert einer der integrierten Typen von Lua sein kann. Das komplizierteste ist, dass es Listen gibt, und diese sind nicht wirklich kompliziert (es ist nur eine Frage der Syntax).

Jetzt warte ich nur darauf, dass jemand fragt, wie der Server-Port bei jedem Start auf einen zufälligen Wert gesetzt wird ...

10
MattJ

Vor kurzem arbeitete ich an einem Projekt und mir wurde klar, dass ich Konditionen in meiner Konfigurationsdatei haben wollte - die zuvor nur eine recht einfache Form hatte:


key = val
key2 = val
name = `hostname`

Ich wollte keine Mini-Sprache schreiben, denn wenn ich es nicht sehr sorgfältig gemacht habe, kann ich nicht die Flexibilität zulassen, die nützlich wäre.

Stattdessen entschied ich mich für zwei Formen:

  1. Wenn die Datei mit "#!" und war ausführbar Ich würde das Ergebnis der Ausführung analysieren.

  2. Sonst hätte ich es so gelesen, wie es ist

Das heißt, ich kann jetzt Leuten erlauben, "Konfigurationsdateien" zu schreiben, die folgendermaßen aussehen:

 #!/usr/bin/Perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

Auf diese Weise bekomme ich die Kraft einer dynamischen Konfigurationsdatei, wenn der Benutzer sie verwenden möchte, und die Einfachheit, dass ich keine eigene Minisprache schreiben muss.

8
Steve Kemp

Jedes (ausreichend langlebige) Konfigurationsdatei-Schema wird schließlich zu einer Programmiersprache. Aufgrund all der von Ihnen beschriebenen Auswirkungen ist es für den Konfigurationsdatei-Designer ratsam, zu erkennen, dass sie eine Programmiersprache verfasst und entsprechend plant, damit sie zukünftige Benutzer nicht mit schlechtem Erbe belastet.

4
Brian

Sie können sich der Theorie der Berechnung zuwenden, um zu definieren, was als Programmiersprache zählt. Wenn das Konfigurationsdateiformat Turing Complete ist, gilt dies als Programmiersprache. Nach dieser Definition zählt ein Dateiformat zur Beschreibung der Ebenen von Sokoban als Programmiersprache (siehe hier ). Unter Turing Complete gibt es noch andere Komplexitätsstufen, die auch von Bedeutung sein können, wie zum Beispiel reguläre Grammatiken und Pushdown-Automaten .

Eine andere Sichtweise besteht darin, dass viele Konfigurationsdateien nur Datenmarkup-fähig sind, wohingegen eine geeignete Programmiersprache Algorithmen implementieren muss. Beispielsweise ist JSON ein Konfigurationsdateiformat, während ECMA Script eine Programmiersprache ist.

3
Parappa

Ich habe eine andere Philosophie über Konfigurationsdateien. Daten darüber, wie eine Anwendung ausgeführt werden soll sind noch Daten und gehören daher in einen Datenspeicher und nicht in Code (eine Konfigurationsdatei IMO ist Code). Wenn Endbenutzer in der Lage sein müssen, die Daten zu ändern, sollte die Anwendung eine Schnittstelle dafür bereitstellen. 

Ich verwende Konfigurationsdateien nur, um auf Datenspeicher zu zeigen.

3
Sarah Mei

Hier sind meine Gedanken:

  1. Um das Laufzeitverhalten einer Anwendung einfach ändern zu können. Dies kann je nach Bedarf von Programmierern oder Nichtprogrammierern erfolgen. Dies kann während der Entwicklung der Fall sein, aber ich sehe häufig Konfigurationsdateien an, um ein Programm jederzeit flexibler zu machen.

  2. Ja. Ich denke, dass Konfigurationsdateien so einfach wie möglich sein sollten, unter der Voraussetzung, dass Sie verschiedene Optionen benötigen, um verschiedene Verhaltensweisen Ihrer Laufzeitumgebung zu steuern. Ich bevorzuge es, Konfigurationseinstellungen zu gruppieren und sie so weit wie möglich zu vereinfachen.

  3. Hängt davon ab, was und warum die Änderung vorgenommen wird. Wenn Benutzer es ändern, sollte ein Frontend erstellt werden, um sie vor den Details zu verbergen. Dasselbe gilt im Allgemeinen oft für Nicht-Entwickler.

  4. Ich verwende oft die "Standard" -Konfiguration, habe aber die Möglichkeit, dies pro System für die tatsächliche Laufzeit zu überschreiben.

Was das Hinzufügen von Logik zur Konfigurationsdatei angeht, würde ich dies vermeiden. Ich denke, es ist besser, wenn die Konfigurationsdatei die Logik in Ihrer Anwendung aktiviert. Das Verhalten in Konfigurationsdateien führt meiner Erfahrung nach zu einem Mangel an Wartbarkeit und Verständnis. Ich ziehe es vor, Konfigurationsdateien so einfach wie möglich zu halten.

2
Reed Copsey

Ich stimme der Prämisse dieser Frage zu. Ich vermeide es, mich in Schwierigkeiten zu bringen, indem ich frühzeitig voraussage, dass dies passieren wird, und daher niemals / mein eigenes Konfigurationssystem rolle. 

  • Entweder verwende ich die Konfigurationsfunktionalität des Betriebssystems (z. B. plist oder gconf oder was immer geeignet ist). 
  • Oder eine einfache Flatfile, die von einem handelsüblichen INI -Parser verarbeitet werden kann.
  • Beißen Sie die Kugel und stecken Sie einen leichten Sprachparser, normalerweise lua, manchmal auch in die Anwendung,
  • Oder speichern Sie Daten in einer SQLite- oder ähnlichen relationalen Datenbank.

Und resignieren Sie sich, um mit meiner Entscheidung zu leben, oder, wenn ich nicht kann, eine der obigen Optionen zu verwenden, die besser zur Anwendung passt.

Es gibt keinen Grund, eine selbst entwickelte Konfigurationslösung zu verwenden. Zum einen ist es für Ihre Benutzer schwieriger, ein neues, anwendungsspezifisches Konfigurationsformat zu erlernen. Zum anderen profitieren Sie von den vielen Fehlerbehebungen und Updates, die bei Verwendung einer Standardlösung kostenlos zur Verfügung stehen. Schlussendlich wird Feature Creep zur Ruhe gebracht, denn Sie können eigentlich nicht einfach eine weitere Funktion hinzufügen, ohne wirklich eine Grundüberholung durchzuführen, da das Konfigurationssystem nicht wirklich in Ihren Händen ist. 

Es hängt davon ab, was Sie mit anderen Entwicklern im Team vereinbaren. Verwenden Sie Konfigurationsdateien wie Konfigurationsdateien oder erstellen Sie eine Model Driven -Anwendung.

Symptome, aus denen die Konfigurationsdatei eine Programmiersprache wird:

  • name = Wertepaare beginnen sich voneinander abzuhängen
  • sie haben das Bedürfnis nach Flusskontrolle (zB if (this) als that )
  • dokumentation für die Konfigurationsdatei wird für die weitere Entwicklung unerlässlich (anstatt nur die Anwendung zu verwenden)
  • bevor der Wert aus config gelesen wird, muss er einen Kontext haben (d. h. Werte hängen von etwas außerhalb der Konfigurationsdatei selbst ab)
1
Milan Babuškov

Config-Dateien sind immer auf dem Weg zu hässlichen, unlogischen "vollwertigen Programmiersprachen". Um gute Programmiersprachen zu entwerfen, sind Kunst und Können erforderlich, und Konfigurationssprachen für Programmiersprachen sind in der Regel abscheulich.

Ein guter Ansatz ist die Verwendung einer schön gestalteten Sprache, z. B. Python oder Ruby, und zum Erstellen einer DSL für Ihre Konfiguration. Auf diese Weise kann Ihre Konfigurationssprache an der Oberfläche einfach bleiben, aber tatsächlich die vollständige Programmiersprache sein.

1
Parand

Ich habe Python-Programme gesehen, bei denen die Konfigurationsdatei is code ist. Wenn Sie nichts Besonderes tun müssen (Bedingungen usw.), unterscheidet es sich kaum von anderen Konfigurationsstilen. z.B. Ich könnte eine Datei config.py mit Sachen machen wie:

num_threads = 13
hostname = 'myhost'

und die einzige Belastung für den Benutzer, verglichen mit (sagen wir) INI -Dateien, besteht darin, dass er Zeichenketten umschließen muss. Zweifellos könnten Sie dasselbe auch in anderen interpretierten Sprachen tun. Sie haben die uneingeschränkte Möglichkeit, Ihre Konfigurationsdatei bei Bedarf zu verkomplizieren, wobei die Gefahr besteht, dass Ihre Benutzer möglicherweise erschreckt werden.

1
John Fouhy

Ich glaube, dass Ihre Frage angesichts des Übergangs zu "fließenden Schnittstellen" sehr relevant ist. Viele Entwickler haben "das Licht gesehen" in Bezug auf XML-konfigurierte Anwendungen. Die Verwendung von XML kann sehr ausführlich und schwer korrekt zu bearbeiten sein (insbesondere wenn kein Schema bereitgestellt wird). Dank einer fließenden Schnittstelle kann der Entwickler die Anwendung in einer domänenspezifischen Sprache mit Hilfe einiger Schlüsselwertpaare aus einer Nur-Text-Konfigurationsdatei (oder möglicherweise Befehlszeilenparametern) konfigurieren. Es macht es auch sehr einfach, neue Instanzen der Anwendung zu Testzwecken einzurichten und zu konfigurieren.

Hier sind meine Antworten auf Ihre Frage:

  • Was ist der wahre Zweck einer config Datei?

Eine Konfigurationsdatei ist eine Möglichkeit, dem Benutzer zu ermöglichen, das Verhalten seines Programms zur Laufzeit anzupassen.

  • Soll versucht werden, Konfigurationsdateien einfach zu halten?

Idealerweise denke ich, dass die Konfigurationsdateien zumindest durch eine fließende Schnittstelle zur Konfiguration des Programms ergänzt werden sollten (dies ist in vielerlei Hinsicht hilfreich). Wenn Sie eine Konfigurationsdatei benötigen, sollte diese sehr einfach gehalten werden, außer Schlüsselpaaren.

  • Wer sollte dafür verantwortlich sein, Änderungen an ihnen vorzunehmen (Entwickler, Benutzer, Administratoren usw.)?

Ich denke, die Antwort darauf hängt von Ihrer Organisation ab. Es sollte in der Verantwortung der Person liegen, die die Software bereitstellt, um sicherzustellen, dass sie ordnungsgemäß konfiguriert ist.

  • Sollten sie quellkontrolliert sein (siehe Frage 3)?

Ich werde diese Antwort von jemand anderem stehlen :) Ich mag die Idee, eine Vorlagenkonfiguration in der Quellcodeverwaltung zu speichern und sie an die Bedürfnisse jedes lokalen Benutzers anzupassen. Die Wahrscheinlichkeit, dass die Konfigurationsdatei eines Entwicklers ein Albtraum eines anderen Entwicklers ist, ist es am besten, Dinge, die je nach Benutzer variieren, außerhalb der Quellcodeverwaltung zu lassen. Eine Vorlage ist auch eine gute Möglichkeit, um die Person, die die Anwendung (oder andere Entwickler) bereitstellt, genau zu sehen, welche Werte für die Konfigurationsdatei gültig sind.

1
Jeffrey Cameron

Ja, Konfigurationsdateien sollten einfach sein. Sie sollten selbst keine "Logik" enthalten. Sie sollten sie als eine Liste von Ausdrücken in if-Anweisungen betrachten, nicht die bedingten Anweisungen in ihrer Gesamtheit.

Sie dienen dazu, dass der Benutzer entscheiden kann, welche der in der Anwendung codierten Optionen verwendet werden soll. Versuchen Sie also nicht, sie zu kompliziert zu machen, da er am Ende selbstsüchtig wird um zu steuern, wie die ursprüngliche Konfigurationsdatei anders konfiguriert werden sollte!

0
gbjbaanb

Eine der Aufgaben der "Oslo" -Aufgabe bei Microsoft besteht darin, die Lösung dieses Problems zuzulassen (wenn auch nicht erforderlich).

  1. Eine Anwendung würde mit Modellen von neuen Komponenten geliefert, die in ihr enthalten sind. Es würden auch vorhandene Modelle verwendet. Beispielsweise kann es einen Webdienst enthalten, sodass das Systemmodell eines Webdienstes wiederverwendet werden kann.
  2. Die Modelle enthalten Metadaten, die sie beschreiben, einschließlich ausreichend Informationen für Werkzeuge, um auf sie entweder textlich oder grafisch zuzugreifen.
  3. Teile der Modelle entsprechen der "Konfiguration"

Dies bedeutet, dass das Äquivalent der heutigen Konfigurationsdateien reich genug sein kann, um sowohl die textuelle als auch die grafische Bearbeitung ihrer Konfiguration zu unterstützen. Das grafische Werkzeug wird mit "Oslo" (Codename "Quadrant") geliefert.

0
John Saunders

Ich werde der Kontrahent sein und einreichen, es ist nur eine Sprache, die mehr enthält, als durch XML dargestellt werden kann. oder wenn XML als Sprache angesehen wird.

Alternativ können die meisten Konfigurationsdateien als Klassen betrachtet werden, jedoch nur mit Eigenschaften und ohne Methoden. Und ohne Methoden glaube ich nicht, dass es eine Sprache ist.

Letztendlich ist "Sprache" eine matschige Abstraktion, aber die Kanten sind mehrdeutig.

0
dkretz

Der Code unserer Anwendungen wird weniger wichtig ... Es gibt Skripte, es gibt alle möglichen Attribute, die das Verhalten von Klassen, Methoden, Methodenargumenten und Eigenschaften definieren. Benutzer können Datenbankauslöser und Datenbankeinschränkungen definieren. Es kann sehr komplizierte Konfigurationsdateien geben. Manchmal kann der Benutzer XSLT-Stylesheets definieren, um die Eingabe und Ausgabe zu bearbeiten, da unsere Systeme offen sein müssen (SOA). Und es gibt Dinge wie BizzTalk, die auch eine komplexe Konfiguration benötigen. Benutzer können komplexe Workflows definieren.

Um mit dieser komplexen Umgebung umgehen zu können, müssen wir besseren Code schreiben, sodass der Code unserer Anwendungen wichtiger wird ...

0
tuinstoel

Config file : "Was ist mein Zweck?"
Sie : "Konfigurieren Sie die Butter."
Konfigurationsdatei : "Ok ..."
Konfigurationsdatei : "Was ist mein Zweck?"
Sie : "Sie konfigurieren Butter."
Konfigurationsdatei : "Oh mein Gott." 

  1. Es gibt keinen "wahren Zweck" einer Konfigurationsdatei. Was auch immer für Ihre Anwendung sinnvoll ist. Im Allgemeinen sollten sich Dinge, die sich zwischen den Maschinen unterscheiden (oder unterscheiden können) und sich während des Anwendungslaufs nicht ändern, möglicherweise in einer Konfigurationsdatei befinden. Standardeinstellungen, Ports und Adressen für andere Dienste sind allesamt gute Kandidaten. Schlüssel und Geheimnisse sind ebenfalls gute Kandidaten, sollten aber aus Sicherheitsgründen getrennt von Ihrer normalen Konfiguration behandelt werden. Ich stimme nicht zu, dass der Zweck einer Konfigurationsdatei darin besteht, schnelle Änderungen zu ermöglichen. Der Zweck sollte darin bestehen, Flexibilität beim Einrichten Ihrer Anwendung zu ermöglichen. Wenn eine Konfigurationsdatei eine schnelle und einfache Möglichkeit ist, diese Flexibilität zuzulassen, ist dies umso besser - aber Sie sollten nicht Ihre Konfigurationsdateien häufig ändern.

  2. Ja und nein. Sollten Sie versuchen, den Code Ihrer Anwendung zu vereinfachen? Ja. Sie sollten versuchen, alles, was Sie schreiben, auf den Punkt zu bringen. Nicht komplizierter als es sein muss. Gleiches gilt für Ihre Konfiguration. Dies ist jedoch sehr anwendungsspezifisch. Hardcoding was in config sein sollte, weil es Ihre Konfiguration "zu kompliziert" machen würde, ist ein schlechtes Design. In der Tat ist der Versuch, "die Dinge einfach zu halten", der Grund dafür, dass Konfigurationsdateien ein riesiges Durcheinander sind. Manchmal ist der einfachste Schritt die Modularisierung. Aus diesem Grund sollten Ihre Konfigurationsdateien in einer allgemein bekannten Programmiersprache geschrieben werden - nicht in einer schrecklichen Konfigurationssprache (lesen Sie: alle "Konfigurationssprachen", saugen Sie ).

  3. Wer Änderungen an den Konfigurationsdateien vornehmen sollte, hängt vollständig von der Anwendung ab. Ich stimme jedoch mit Miniquark überein, wer die Anwendung bereitstellt, sollte für die Konfiguration verantwortlich sein. 

  4. Quellcodeverwaltung alles, was Sie können. Die Quellensteuerung ist großartig. Sie können das Material ganz einfach rückgängig machen, und Sie haben eine vollständige Historie der vorgenommenen Änderungen und eine Aufzeichnung, wer diese Änderungen vorgenommen hat. Also warum nicht?

0
B T

Ich bin ein großer Fan von Python-Programmen als Konfigurationsdateien, insbesondere für Daemons. Ich mag es, den Daemon bis auf den "Konfigurationsport" komplett leer zu machen. Das Python-Programm stellt dann eine Verbindung zum Daemon her und erstellt anschließend Objekte im Daemon und verbindet diese, um die gewünschte Konfiguration zu erstellen. Sobald alles eingerichtet ist, kann der Daemon alleine laufen. Die Vorteile sind natürlich, dass Sie eine vollwertige Programmiersprache zum Schreiben Ihrer Konfigurationsdateien erhalten. Da Sie bereits über eine Möglichkeit verfügen, mit einem anderen Programm mit dem Daemon zu sprechen, können Sie sie zum Debuggen und zum Abrufen von Statistiken verwenden. Der größte Nachteil besteht darin, dass Sie sich jederzeit mit Nachrichten aus einem anderen Programm befassen müssen.

0
Tim Stack