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. Je reviens de plus en plus à la prise de conscience que j'ai eue pour la première fois en apprenant Lisp: il y a peu de différence entre les données et le code. Cela semble doublement vrai pour les fichiers de configuration. Considéré 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 la division du travail, comme qui devrait être responsable de la modification des fichiers de configuration.
Le glissement du fichier de configuration au 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 comme où écrire les journaux, où rechercher les données, les noms d'utilisateur et les mots de passe, etc. Mais ensuite, ils commencent à se développer: les fonctionnalités commencent à pouvoir être activées ou désactivées, les temps 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 la machine est Y). À un certain moment, le fichier de configuration devient un langage spécifique au domaine, et un langage mal écrit en plus.
Maintenant que je me suis lancé pour préparer le terrain, voici mes questions:
- Quel est le véritable objectif d'un fichier de configuration?
- Faut-il essayer de garder les fichiers de configuration simples?
- Qui devrait être responsable de leur apporter des modifications (développeurs, utilisateurs, administrateurs, etc.)?
- Devraient-ils être contrôlés à la source (voir question 3)?
Comme je l'ai dit plus tôt, mes réponses à ces questions changent constamment, mais pour le moment, je pense:
- pour permettre à un non-programmeur de changer rapidement de gros morceaux de comportement
- oui, tout ce qui n'est pas à grain grossier devrait être dans le code
- les utilisateurs devraient être responsables des fichiers de configuration et les programmeurs devraient être responsables d'une couche de configuration 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 doit être