À quel moment un fichier de configuration devient-il un langage de programmation?

https://stackoverflow.com/questions/648246

22-07-2019
|

Question

Cela fait un moment que je réfléchis aux fichiers de configuration et à leur relation avec le code et, en fonction du jour et de la direction du vent, mes opinions semblent changer. De plus en plus, je reviens toujours à la réalisation que j’avais eue lors de mon apprentissage de Lisp: il y a peu de différence entre données et code. Cela semble doublement vrai pour les fichiers de configuration. Regardé sous le bon angle, un script Perl n’est guère plus qu’un fichier de configuration pour Perl. Cela a tendance à avoir des conséquences assez lourdes pour des tâches telles que l'AQ et les divisions du travail, par exemple l'identité de la personne qui devrait être responsable de la modification des fichiers de configuration.

Le glissement du fichier de configuration vers un langage à part entière est généralement lent et semble être motivé par le désir de disposer d’un système générique. La plupart des projets semblent commencer modestement avec quelques éléments de configuration tels que l’emplacement où écrire les journaux, où rechercher les données, les noms d’utilisateur et les mots de passe, etc. Mais ils commencent à se développer le minutage et l'ordre des opérations commencent à être contrôlés et, inévitablement, quelqu'un veut commencer à y ajouter de la logique (par exemple, utilisez 10 si la machine est X et 15 si elle est Y). À un moment donné, le fichier de configuration devient un langage spécifique à un domaine et un langage mal écrit.

Maintenant que je me suis précipité pour préparer le terrain, voici mes questions:

Quel est le véritable but d'une configuration fichier?
Faut-il essayer de garder Fichiers de configuration simples?
Qui devrait être responsable de faire modifications à leur apporter (développeurs, utilisateurs, administrateurs, etc.)?
Devraient-ils être contrôlés à la source? (voir question 3)?

Comme je l'ai dit précédemment, mes réponses à ces questions changent constamment, mais pour le moment je me dis:

pour permettre à un non-programmeur de changer gros morceaux de comportement rapidement
oui, tout ce qui n'est pas grossier grained devrait être dans le code
les utilisateurs devraient être responsables de les fichiers de configuration et les programmeurs devraient être responsable d'une configuration couche entre les fichiers de configuration et le code qui donne un contrôle plus fin de l'application
non, mais la couche intermédiaire à grain plus fin devrait être

La solution

Des questions très intéressantes!

J'ai tendance à limiter mes fichiers de configuration à une très simple "clé = valeur". Je suis tout à fait d’accord avec vous pour dire que les fichiers de configuration peuvent très rapidement devenir des programmes à part entière. Par exemple, toute personne ayant déjà essayé de & configurer; configurer " OpenSER connaît le sentiment dont vous parlez: ce n'est pas de la configuration, c'est de la programmation (douloureuse).

Lorsque vous avez besoin que votre application soit très & configurable " d’une manière que vous ne pouvez pas imaginer aujourd’hui, vous avez réellement besoin d’un système de plugins . Vous devez développer votre application de manière à ce que quelqu'un d'autre puisse coder un nouveau plugin et l'intégrer à votre application à l'avenir.

Donc, pour répondre à vos questions:

Quel est le véritable but d'un fichier de configuration?

Je dirais, pour permettre aux personnes qui installeront votre application de pouvoir paramétrer certains paramètres liés au déploiement, tels que le nom d'hôte, le nombre de threads, les noms des plugins nécessaires et les paramètres de déploiement de ceux-ci. plugins (consultez la configuration de FreeRadius pour un exemple de ce principe), etc. Ce n’est certainement pas le lieu pour exprimer la logique commerciale.
Faut-il essayer de garder les fichiers de configuration simples?

Certainement. Comme vous l'avez suggéré, "programmation" dans un fichier de configuration est horrible. Je pense que cela devrait être évité.
Qui devrait être responsable de leur modification (développeurs, utilisateurs, administrateurs, etc.)?

En général, je dirais aux administrateurs qui déploient l'application.
Devraient-ils être contrôlés par la source (voir question 3)?

Je ne contrôle généralement pas les fichiers de configuration eux-mêmes, mais je fais le contrôle de sources d'un fichier de configuration de modèle, avec tous les paramètres et leurs valeurs par défaut, ainsi que des commentaires décrivant leurs tâches. Par exemple, si un fichier de configuration s'appelle database.conf , je contrôle généralement un fichier nommé database.conf.template . Maintenant, bien sûr, je parle de ce que je fais en tant que développeur . En tant qu'administrateur , je souhaiterais peut-être contrôler par la source les paramètres réels que j'ai choisis pour chaque installation. Par exemple, nous gérons quelques centaines de serveurs à distance et nous devons suivre leurs configurations: nous avons choisi de le faire avec le contrôle de la source.

Modifier : Bien que je pense que ce qui précède est vrai pour la plupart des applications, il y a toujours des exceptions, bien sûr. Votre application peut permettre à ses utilisateurs de configurer de manière dynamique des règles complexes, par exemple. La plupart des clients de messagerie permettent aux utilisateurs de définir des règles pour la gestion de leurs e-mails (par exemple, "tous les e-mails provenant de" John Doe "et ne m'ayant pas dans le champ À: doivent être ignorés"). Un autre exemple est une application qui permet à l'utilisateur de définir une nouvelle offre commerciale complexe. Vous pouvez également penser aux applications telles que Cognos, qui permettent à leurs utilisateurs de créer des rapports de base de données complexes. Le client de messagerie offrira probablement à l'utilisateur une interface simple pour définir les règles, ce qui générera un fichier de configuration complexe (ou même peut-être un peu de code). D'autre part, la configuration définie par l'utilisateur pour les offres commerciales peut être sauvegardée dans une base de données, de manière structurée (ni une structure simple clé = valeur, ni une portion de code). Et certaines autres applications peuvent même permettre à l'utilisateur de coder en python ou en VB, ou dans un autre langage compatible avec l'automatisation. En d'autres termes ... votre kilométrage peut varier.

Autres conseils

Ok. Vous aurez des utilisateurs qui veulent une configuration vraiment simple, vous devriez la leur donner. En même temps, vous aurez des demandes constantes de "Pouvez-vous ajouter ceci? Comment faire dans le fichier de configuration? & Quot ;, Je ne vois pas pourquoi vous ne pouvez pas prendre en charge les deux groupes.

Le projet sur lequel je travaille actuellement utilise Lua pour son fichier de configuration. Lua est un langage de script et cela fonctionne assez bien dans ce scénario. Un exemple de notre configuration par défaut est disponible.

Vous remarquerez qu'il s'agit principalement d'instructions key = value, où value peut être l'un des types intégrés de Lua. Les listes les plus compliquées existent, et elles ne le sont pas vraiment (c'est juste une question de syntaxe).

Maintenant, j'attends juste que quelqu'un demande comment configurer le port de leur serveur sur une valeur aléatoire chaque fois qu'ils le démarrent ...

Récemment, je travaillais sur un projet et je me suis rendu compte que je voulais avoir des conditions dans mon fichier de configuration - ce qui était auparavant très simple:


key = val
key2 = val
name = `hostname`

Je ne voulais pas écrire un mini-langage, car si je ne le faisais pas très soigneusement, je ne pouvais pas permettre la flexibilité qui serait utile.

Au lieu de cela, j'ai décidé que j'aurais deux formes:

Si le fichier a commencé par "#!" et était exécutable, j'analyserais le résultat de son exécution.
Sinon, je le lirais tel quel

Cela signifie que je peux maintenant permettre aux gens d'écrire des "fichiers de configuration". qui ressemblent à ceci:

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

Ainsi, je reçois la puissance d'un fichier de configuration dynamique si l'utilisateur souhaite l'utiliser, et la simplicité de ne pas avoir à écrire mon propre mini-langage.

Chaque schéma de fichier de configuration (de durée de vie suffisante) finit par devenir un langage de programmation. En raison de toutes les implications que vous décrivez, il est sage que le concepteur de fichiers de configuration réalise qu’il est en train de créer un langage de programmation et de planifier en conséquence, afin de ne pas encombrer les futurs utilisateurs de mauvais héritage.

J'ai une philosophie différente à propos des fichiers de configuration. Les données sur la manière dont une application doit être exécutée sont toujours des données et appartiennent donc à un magasin de données, pas à du code (un fichier de configuration IMO est un code). Si les utilisateurs finaux doivent pouvoir modifier les données, l’application doit fournir une interface pour le faire.

J'utilise uniquement les fichiers de configuration pour pointer vers les magasins de données.

Vous pouvez vous tourner vers la théorie du calcul pour définir ce qui compte comme langage de programmation. Si le format de votre fichier de configuration est Turing Complete , il compte raisonnablement comme langage de programmation. Par cette définition, un format de fichier décrivant les niveaux de Sokoban est considéré comme un langage de programmation (voir < a href = "http://web.cs.ualberta.ca/~joe/Preprints/Sokoban/index.html" rel = "nofollow noreferrer"> ici ). Turing Complete peut également compter d'autres niveaux de complexité, tels que les Grammars ordinaires et < a href = "http://en.wikipedia.org/wiki/Pushdown_automaton" rel = "nofollow noreferrer"> Automate à pile .

Une autre façon de voir les choses est que beaucoup de fichiers de configuration ne sont capables que du balisage de données, alors qu'un langage de programmation approprié doit être capable de mettre en oeuvre algorithmes . Par exemple, JSON est un format de fichier de configuration, alors que ECMA Script est un langage de programmation.

Voici mes pensées:

Permet de modifier facilement le comportement à l'exécution d'une application. Cela peut être par des programmeurs ou des non-programmeurs, en fonction des besoins. Cela peut arriver pendant le développement, mais j’aperçois souvent les fichiers de configuration comme un moyen de rendre un programme plus flexible à tout moment.
Oui. Je pense que les fichiers de configuration devraient être aussi simples que possible, étant donné que vous aurez peut-être besoin de différentes options pour contrôler différents comportements de votre environnement d'exécution. Je préfère regrouper les paramètres de configuration et les simplifier le plus possible.
Dépend de quoi et pourquoi le changement est fait. Si les utilisateurs veulent le changer, un serveur frontal doit être créé pour les masquer des détails. Il en va souvent de même pour les non-développeurs en général.
Je contrôle souvent la source du " défaut " configuration, mais vous pouvez le remplacer par le système pour l'exécution réelle.

Pour ce qui est d’ajouter de la logique au fichier de configuration, je l’éviterais. Je pense qu'il est préférable de simplement activer le fichier de configuration sur la logique de votre application. Le comportement dans les fichiers de configuration entraîne un manque de maintenabilité et de compréhension, selon mon expérience. Je préfère fortement garder les fichiers de configuration aussi simples que possible.

J'ai tendance à être d'accord avec le principe de cette question. J'évite de m'attirer des ennuis en prédisant à l'avance que cela va arriver, et donc ne jamais lancer mon propre système de configuration.

Soit j'utilise la configuration du système d'exploitation (telle qu'un plist, ou gconf ou ce qui est approprié),
Ou un simple fichier plat, pouvant être géré par un analyseur INI standard.
Mordez la balle et insérez un analyseur de langage léger, généralement lua, parfois tcl, dans l'application,
Ou stockez des données dans une base de données relationnelle SQLite ou similaire.

Et me résigner à vivre avec la décision que j'ai prise ou, si je ne peux pas, refactoriser l'utilisation de l'un des choix ci-dessus qui convient le mieux à l'application.

Le fait est qu'il n'y a pas vraiment de raison d'utiliser une solution de configuration maison. D'une part, il est plus difficile pour vos utilisateurs d'avoir à apprendre un nouveau format de configuration spécifique à l'application. D'autre part, vous bénéficiez de nombreuses corrections de bugs et mises à jour gratuites avec l'utilisation d'une solution standard. Enfin, le glissement de fonctionnalités est mis de côté, car, eh bien, vous ne pouvez pas simplement ajouter une fonctionnalité de plus sans vraiment procéder à une refonte majeure, car le système de configuration n'est pas vraiment entre vos mains.

Cela dépend de ce que vous acceptez avec les autres développeurs de l'équipe. Utilisez-vous des fichiers de configuration comme des fichiers de configuration ou créez-vous une application dirigée par le modèle ?

Symptômes du fichier de configuration devenant un langage de programmation:

Les paires nom = valeur commencent à dépendre les unes des autres
vous sentez le besoin d'avoir un contrôle de flux (ex. si (cela) que cela )
la documentation du fichier de configuration devient essentielle pour poursuivre le développement (au lieu d'utiliser simplement l'application)
avant que la valeur de config ne soit lue, un certain contexte est nécessaire (c’est-à-dire que les valeurs dépendent d’un élément externe au fichier de configuration lui-même)

Les fichiers de configuration sont invariablement en train de devenir des "langages de programmation à part entière" laids et illogiques. Il faut de l'art et des compétences pour concevoir de bons langages de programmation, et les langages de configuration transformés en langages de programmation tendent à être horribles.

Une bonne approche consiste à utiliser un langage bien conçu, par exemple python ou ruby, et à l'utiliser pour créer un DSL pour votre configuration. De cette façon, votre langage de configuration peut rester simple en surface, mais en réalité être le langage de programmation à part entière.

Je pense que votre question est très pertinente compte tenu du passage aux "interfaces fluides". De nombreux développeurs ont "vu la lumière". en ce qui concerne les applications configurées XML. L'utilisation de XML peut être très détaillée et difficile à modifier correctement (surtout si aucun schéma n'est fourni). Le fait de disposer d’une interface fluide permet au développeur de configurer l’application dans un langage spécifique à un domaine à l’aide de certaines paires clé-valeur d’un fichier de configuration en texte brut (ou éventuellement de paramètres de ligne de commande). Cela facilite également la configuration et la configuration de nouvelles instances de l’application pour les tests ou autres.

Voici mes réponses à votre question:

Quel est le véritable but d'une configuration fichier?

Un fichier de configuration permet à l'utilisateur de personnaliser le comportement de son programme au moment de l'exécution.

Faut-il essayer de garder Fichiers de configuration simples?

Idéalement, je penserais que les fichiers de configuration devraient au moins être complétés par une interface fluide pour configurer le programme (utile à de nombreux égards). Si vous avez besoin d’un fichier de configuration, il devrait rester très simple, rien d’autre que des paires clé-valeur.

Qui devrait être responsable de faire modifications à leur apporter (développeurs, utilisateurs, administrateurs, etc.)?

Je pense que la réponse à cette question dépend de votre organisation. Il incombe à la personne qui déploie le logiciel de s’assurer qu’il est correctement configuré.

Devraient-ils être contrôlés à la source (voir question 3)?

Je vais voler cette réponse à quelqu'un d'autre :) J'aime l'idée de stocker une configuration de modèle dans le contrôle de source et de la modifier pour répondre aux besoins de chaque utilisateur local. Il est fort probable que le fichier de configuration d'un développeur constitue le cauchemar d'un autre développeur. Il est donc préférable de laisser les choses qui varient d'un utilisateur à l'autre du contrôle de source. Avoir un modèle est également un bon moyen de laisser la personne qui déploie l'application (ou d'autres développeurs) voir exactement quelles valeurs sont valides pour le fichier de configuration.

J'ai vu des programmes python dans lesquels le fichier de configuration est un code . Si vous n'avez rien de spécial à faire (conditionnel, etc.), cela ne sera pas très différent des autres styles de configuration. par exemple. Je pourrais créer un fichier config.py avec des éléments tels que:

num_threads = 13
hostname = 'myhost'

et le seul fardeau qui pèse sur l’utilisateur, comparé aux fichiers (par exemple) INI, c’est qu’ils ont besoin de mettre des chaînes autour des chaînes. Nul doute que vous pourriez faire la même chose dans d'autres langages interprétés. Il vous donne la possibilité illimitée de compliquer votre fichier de configuration si nécessaire, au risque d'effrayer vos utilisateurs.

Oui, les fichiers de configuration doivent être simples. Ils ne doivent contenir aucune "logique" - pensez à eux comme à une liste d'expressions dans des instructions if, et non aux instructions conditionnelles dans leur intégralité.

Ils sont là pour permettre à l'utilisateur de décider laquelle des options codées dans l'application doit être utilisée, alors n'essayez pas de les compliquer, cela finira par être contre-productif - vous pourriez finir par écrire fichiers de configuration simples pour contrôler la configuration du fichier de configuration original, sinon!

L’un des objectifs de la base de données "Oslo" travailler chez Microsoft est de permettre (bien que ce n’exige pas) la résolution de ce problème.

Une application serait livrée avec des modèles de tous les nouveaux composants qu’elle inclut. Il utiliserait également les modèles existants. Par exemple, il peut inclure un service Web afin de pouvoir réutiliser le modèle système d’un service Web.
Les modèles comprendront des métadonnées les décrivant, ainsi que suffisamment d'informations pour permettre aux outils d'y accéder, sous forme de texte ou de graphisme.
Certaines parties des modèles correspondront à la "configuration"

Cela signifie que l’équivalent des fichiers de configuration d’aujourd’hui peut être suffisamment riche pour prendre en charge l’édition textuelle et graphique de leur configuration. L'outil graphique sera fourni avec "Oslo". (nom de code "Quadrant").

Je serai le contrarian et soumettrai que ce n’est qu’un langage qui englobe plus que ce qui peut être représenté par XML; ou bien quand XML est considéré comme un langage.

Alternativement, la plupart des fichiers de configuration peuvent être considérés comme des classes, mais avec uniquement des propriétés et aucune méthode. Et sans méthodes, je ne pense pas que ce soit un langage.

En fin de compte, "langue". est une abstraction spongieuse, mais oui, les bords sont ambigus.

Le code de nos applications devient moins important ... Il existe des scripts, il y a toutes sortes d'attributs qui définissent le comportement des classes, méthodes, arguments de méthodes et propriétés. Les utilisateurs peuvent définir des déclencheurs de base de données et des contraintes de base de données. Il peut y avoir des fichiers de configuration très compliqués. Parfois, l'utilisateur peut définir des feuilles de style XSLT pour manipuler les entrées et les sorties, car nos systèmes doivent être ouverts (SOA). Et il y a des choses comme BizzTalk qui nécessitent également une configuration complexe. Les utilisateurs peuvent définir des workflows complexes.

Nous devons écrire un meilleur code pour traiter cet environnement complexe, pour que le code de nos applications devienne plus important ...

Je suis un grand partisan de l’utilisation des programmes python en tant que fichiers de configuration, en particulier pour les démons. J'aime bien faire en sorte que le démon soit complètement vide de configuration, à l'exception du "port de configuration". Le programme python se connecte ensuite au démon et crée des objets dans le démon, puis les relie entre eux pour créer la configuration souhaitée. Une fois que tout est configuré, vous pouvez laisser le démon s'exécuter seul. Les avantages, bien sûr, sont que vous obtenez un langage de programmation complet pour écrire vos fichiers de configuration et, comme vous avez déjà un moyen de parler au démon d'un autre programme, vous pouvez l'utiliser pour le débogage et obtenir des statistiques. Le principal inconvénient est de devoir traiter les messages d’un autre programme à tout moment.

Fichier de configuration : "Quel est mon but?"

Vous : "Configurez le beurre."

Fichier de configuration : "Ok ... "
Fichier de configuration : "Quel est mon but?"

Vous : "Vous configurez le beurre."

Fichier de configuration : "Oh mon dieu."

Il n'y a pas de "véritable objectif" d'un fichier de configuration. C'est ce qui fait sens pour votre application. En général, les éléments qui diffèrent (ou peuvent différer) d'une machine à l'autre et qui ne changent pas au milieu de l'exécution de votre application devraient probablement figurer dans un fichier de configuration. Les valeurs par défaut, les ports et les adresses d'autres services sont d'excellents candidats. Les clés et les secrets sont également d'excellents candidats mais doivent être traités séparément de votre configuration normale pour des raisons de sécurité. Je ne suis pas d'accord sur le fait que le but d'un fichier de configuration est de permettre des modifications rapides. Le but devrait être de permettre une flexibilité dans la configuration de votre application. Si un fichier de configuration est un moyen rapide et facile d’accorder cette flexibilité, tant mieux - mais vous ne devriez pas vouloir que vos fichiers de configuration changent fréquemment.
Oui et non. Devriez-vous essayer de simplifier le code de votre application? Oui. Vous devriez essayer de rendre tout ce que vous écrivez simple et précis. Pas plus compliqué que nécessaire. Même est vrai de votre config. Cependant, ceci est très spécifique à l'application. Coder en dur ce qui devrait être dans la configuration car cela rendrait votre configuration "trop ??compliquée" est mauvaise conception. En fait, essayez de "garder les choses simples". C'est pourquoi les fichiers de configuration finissent par être un gâchis géant. Parfois, le plus simple est de modulariser. C'est pourquoi vos fichiers de configuration doivent être écrits dans un langage de programmation généraliste bien connu - pas dans un langage de configuration épouvantable (lire: toutes les" langues de configuration "succales ).
Encore une fois, la modification des fichiers de configuration dépend entièrement de l'application. Mais je suis d’accord avec Miniquark, celui qui déploie l’application devrait être en charge de la configuration.
La source contrôle tout ce que vous pouvez. Le contrôle de la source est génial. Vous pouvez facilement revenir en arrière, vous avez un historique complet des modifications que vous avez apportées et une liste de leurs auteurs. Alors pourquoi pas?

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow