À quel moment un fichier de configuration devient-il un langage de programmation?
Je réfléchis depuis un moment aux fichiers de configuration et à leur relation avec le code et, selon le jour et 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 du LISP: il y a peu de différence entre les données et le 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 d’avoir 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'un fichier de configuration?
- Devrait-on essayer de garder les fichiers de configuration simples?
- Qui devrait être responsable de leur modification (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 pense:
- permettre à un non-programmeur de changer rapidement de gros morceaux de comportement
- oui, tout ce qui n'est pas à grain grossier devrait être en code
- les utilisateurs doivent être responsables des fichiers de configuration et les programmeurs doivent être responsables de la couche de configuration entre les fichiers de configuration et du code permettant un contrôle plus fin de l'application
- non, mais la couche intermédiaire à grain fin devrait être
Des questions très intéressantes!
J'ai tendance à limiter mes fichiers de configuration à un format très simple "clé = valeur", car je suis tout à fait d'accord avec vous sur le fait que les fichiers de configuration peuvent très rapidement devenir des programmes complets. Par exemple, quiconque a déjà essayé de "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 vraiment besoin d'un plugins system . Vous devez développer votre application de manière à ce que quelqu'un d'autre puisse coder un nouveau plug-in et le relier à votre application à l'avenir.
Alors, 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 dont vous avez besoin et les paramètres de déploiement de ces plugins (cochez configuration de FreeRadius pour un exemple de ce principe), etc. Ce n’est certainement pas l’endroit idéal pour exprimer la logique commerciale.
Devrait-on essayer de garder les fichiers de configuration simples?
Absolument. Comme vous l'avez suggéré, "programmer" dans un fichier de configuration est horrible. Je crois que cela devrait être évité.
Qui devrait être responsable de leur modification (développeurs, utilisateurs, administrateurs, etc.)?
En général, je dirais les administrateurs, qui déploient l'application.
Devraient-ils être contrôlés à la source (voir question 3)?
Je ne contrôle généralement pas les fichiers de configuration eux-mêmes, mais I do contrôle-source 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 , il se peut que je veuille contrôler à 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 source.
Edit : 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 courriels (par exemple, "tous les courriels provenant de" john doe "et ne m'ayant pas dans le champ À: doivent être supprimés"). Un autre exemple est une application qui permet à l'utilisateur de définir une nouvelle offre commerciale complexe. Vous pouvez également penser à des 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.
D'accord. Vous aurez des utilisateurs qui veulent une configuration vraiment simple, vous devriez la leur donner. En même temps, vous aurez des requêtes constantes de "Pouvez-vous ajouter ceci? Comment puis-je faire dans le fichier de configuration?", Je ne vois pas pourquoi vous ne pouvez pas supporter 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. Il existe un exemple de notre configuration default .
Vous noterez 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, 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, parce que si je ne le faisais pas très soigneusement, je ne pourrais 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
}
De cette façon, je reçois la puissance d'un fichier de configuration dynamique si l'utilisateur veut 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 fichier de configuration réalise qu'il est en train de créer un langage de programmation et de planifier en conséquence, de peur de surcharger les futurs utilisateurs de mauvais héritage.
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 alors raisonnablement comme langage de programmation. Selon cette définition, un format de fichier décrivant les niveaux de Sokoban compte comme langage de programmation (voir ici ). Sous Turing Complete, il existe d'autres niveaux de complexité qui peuvent également compter, tels que Grammars réguliers et Pushdown Automata .
Une autre façon de voir les choses est que beaucoup de fichiers de configuration ne sont capables que de baliser les données, alors qu'un langage de programmation approprié doit être capable de mettre en œuvre algorithms . Par exemple, JSON est un format de fichier de configuration, alors que ECMA Script est un langage de programmation.
J'ai une philosophie différente sur les 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.
Voici mes pensées:
Permettre de modifier facilement le comportement d'exécution d'une application. Cela peut être par des programmeurs ou des non-programmeurs, en fonction des besoins. Cela peut être pendant le développement, mais je considère 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 autant que 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 configuration "par défaut" de la source, mais je dispose d'un moyen de la remplacer par 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 la prémisse de cette question. J'évite les ennuis en prédisant très tôt que cela va arriver, et donc 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 tout autre logiciel approprié),
- Ou un simple fichier plat, qui peut être géré par quelque chose comme un analyseur INI.
- Mordez la balle et branchez 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 pour utiliser 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 êtes d'accord 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 Model Driven ?.
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 (ceci) 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 langage de programmation ont tendance à être épouvantables.
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.
J'ai vu des programmes python dans lesquels le fichier de configuration est 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 choses comme:
num_threads = 13
hostname = 'myhost'
et le seul fardeau qui pèse sur l'utilisateur, comparé à (par exemple) INI fichiers, est qu'il faut mettre "" 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.
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 en 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 l'installation 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'un fichier de configuration ?
Un fichier de configuration permet à l'utilisateur de personnaliser le comportement de son programme au moment de l'exécution.
- Devrait-on essayer de garder Des 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 leur apporter Des modifications (développeurs, utilisateurs, Administrateurs, etc.)?
Je pense que la réponse à cette question dépend de votre organisation. Il devrait incomber à la personne qui déploie le logiciel de s’assurer qu’il est correctement configuré.
- Devraient-ils être contrôlés par 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.
Oui, les fichiers de configuration doivent être simples. Ils ne doivent pas contenir de «logique» eux-mêmes - considérez-les comme une liste d'expressions dans des déclarations if, pas des déclarations conditionnelles dans leur intégralité.
Ils sont là pour permettre à l'utilisateur de choisir les options codées dans l'application à utiliser, alors n'essayez pas de les compliquer, cela finira par être contre-productif - vous risquez peut-être d'écrire de simples fichiers de configuration. pour contrôler la configuration du fichier de configuration d'origine sinon!
L’un des objectifs du travail "Oslo" de Microsoft est de permettre (bien que pas obliger) 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 que les outils puissent y accéder, sous forme de texte ou de graphique.
- Des parties des modèles correspondront à la "configuration"
Cela signifie que l’équivalent des fichiers de configuration actuels 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 lorsqu'il 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, "langage" est une abstraction spongieuse, mais oui, les bords sont ambigus.
Le code de nos applications devient moins important ... Il y a 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, de sorte que le code de nos applications devienne plus important ...
Fichier de configuration : "Quel est mon but?"
You : "Configurez le beurre."
Fichier de configuration : "Ok ..."
Fichier de configuration : "Quel est mon but?"
You : "Vous configurez butter."
Fichier de configuration : "Oh mon dieu."
Il n'y a pas de "vrai but" 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’autoriser cette flexibilité, tant mieux - mais vous 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. Le codage en dur de ce qui devrait être dans la configuration car cela rendrait votre configuration "trop compliquée" est une mauvaise conception. En fait, essayer de "garder les choses simples" est la raison pour laquelle 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: tous les "langages de configuration" suck ).
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?
Je suis un grand fan de l'utilisation de programmes python en tant que fichiers de configuration, en particulier pour les démons. J'aime prendre le parti de rendre le démon 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. L'inconvénient majeur est de devoir gérer à tout moment les messages d'un autre programme.