La «convention sur la configuration» ne contrevient-elle pas aux principes de base de la programmation?


51

Je regardais le framework WPF MVVM Caliburn.Micro et ai lu que beaucoup d'éléments standard sont basés sur des conventions de dénomination .

Par exemple, liaison automatique des propriétés de la vue aux propriétés du modèle de vue. Bien que cela semble être pratique (supprime du code standard), ma première réaction instinctive est qu’il n’est pas tout à fait évident pour un nouveau programmeur qui lira ce code. En d'autres termes, la fonctionnalité de l'application n'est pas complètement expliquée par son propre code, mais aussi par la documentation du framework.

MODIFIER:

Donc, cette approche s'appelle convention sur la configuration. N'ayant pu trouver aucune question à ce sujet, j'ai modifié ma question:

Ma question est:

La convention sur la configuration est-elle un moyen correct de simplifier les choses ou viole-t-elle certains principes de programmation (et si oui, lesquels)?


8
La plupart des approches / principes violent certaines autres approches / principes dans une certaine mesure. C'est surtout une question de priorités et de compromis.
Joachim Sauer le

1
C'est vrai, mais je trouve la différence énoncée dans ma question un peu étrange et, par conséquent, je suis intéressé par les compromis spécifiques et éventuellement par la violation des principes lors de l'utilisation de la convention par rapport à la configuration.
Geerten

Le concept de traçabilité du logiciel est pertinent ici. Les programmeurs utilisent des outils tels que grep, mais ont besoin d'outils plus performants pour suivre les utilisations du code généré. Par exemple, les outils doivent indiquer plus clairement que la classe css "id-utilisateur" est liée à la méthode générée getUserId () et à la colonne de table id_utilisateur.
Macneil

Réponses:


49

Je ne considère pas "une application doit être entièrement expliquée par son propre code", principe fondamental de la programmation. Il y a des tas de choses qui ne s'expliquent pas en regardant simplement le code d'une application. Outre la connaissance des éléments de base du langage de programmation lui-même (syntaxe et sémantique), vous devez connaître les conventions. Si un identifiant en Java commence par une lettre majuscule, il s'agit d'un type. Vous devez connaître bon nombre de ces conventions.

La convention sur la configuration consiste à réduire le nombre de décisions que le programmeur doit prendre à propos de choses. Pour certaines choses, cela est évident - personne n’envisagerait d’utiliser une langue dans laquelle la capitalisation des types est quelque chose que vous devez déclarer au sommet de votre programme - mais cela n’est pas si évident.

Équilibrer convention et configuration est une tâche difficile. Trop de convention peut rendre le code déroutant (prenons les variables implicites de Perl, par exemple). Une trop grande liberté du côté du programmeur peut rendre les systèmes difficiles à comprendre, car les connaissances acquises d’un système sont rarement utiles lors de l’étude d’un autre.

Un bon exemple de convention aide le programmeur à écrire des plug-ins Eclipse. En regardant un plugin que je n'ai jamais vu, je sais tout de suite beaucoup de choses à ce sujet. La liste des dépendances est dans MANIFEST.MF, les points d’extension sont dans plugin.xml, le code source est sous "src", et ainsi de suite. Si ces éléments devaient être définis par le programmeur, chaque plug-in Eclipse serait différent et la navigation dans le code serait beaucoup plus difficile.


4
+1: le développement logiciel est déjà assez compliqué. Si vous pouvez éviter la complexité des choses que vous contrôlez, faites-le. Enregistrez la complexité pour les endroits où vous en avez absolument besoin.
scrwtp

1
Merci pour l'explication claire sur la différence et l'équilibre.
Geerten

3
"Si un identifiant en Java commence par une majuscule, il s'agit d'un type." - que le type dépende du contexte syntaxique et non du modèle de dénomination, les conventions de dénomination Java n'affectent pas la "configuration de compilation". Êtes-vous sûr que c'est un exemple valable? Le dernier exemple n'est pas non plus correct - il s'agit de "conventions de configuration" et non de "convention sur la configuration". Vous dites de bonnes choses mais elles ont peu à voir avec le principe de subj.
Den

4
Ne sur-analysez pas les exemples, ce ne sont que des exemples. Le premier est juste un exemple de convention, le dernier est un exemple où la convention est une bonne chose. L'exemple Perl est un exemple où trop de conventions (implicites) sont une mauvaise chose (IMO, je devrais ajouter).
JesperE

1
Ce que je déteste, c’est lorsque la convention sur la configuration devient une convention sans configuration… dans ce dernier cas, vous avez tendance à vous faire piéger avec un code base, il peut être difficile de l’intégrer à d’autres outils.
Andy

77

Donné +1 à @JesperE, et souhaite ajouter quelque chose:

enfreint-il certains principes de programmation

Oui, "convention over configuration" viole le principe "explicite vaut mieux qu'implicite" (regardez, par exemple, "Zen-Of-Python" ).

D'autre part, la configuration opposée "configuration sur convention" a tendance à violer "Simple est meilleur que complexe", et pire, enfreint le principe DRY de manière subtile, car vous devez répéter les noms utilisés dans votre code également dans votre configuration. .


4
C'est la réponse la plus directe à la question!
Joachim Sauer le

C'est la bonne réponse parmi les deux plus votés.
Den

+1 pour "explicite vaut mieux qu'implicite"
Justin Ohms

12
Ce que je préfère dans cette réponse, c’est qu’elle met implicitement en évidence la réalité, que les principes d’un bon développement logiciel sont souvent en tension. L'ingénierie consiste à équilibrer ces tensions de manière appropriée pour votre contexte et votre application spécifiques.
Chris Krycho

Bonne réponse. Pour approfondir le commentaire de @Chris Krycho, la bonne chose à propos des normes ou des principes logiciels, c'est que vous en avez tellement à choisir. :-)
user949300

9

Certaines des "conventions sur la configuration" se résument à des valeurs par défaut raisonnables. Vous ne devriez avoir à configurer que quelque chose pour l'utiliser à des fins non standard. Je dois comparer Struts à Rails ici. Dans Rails, vous devez placer vos "actions / écrans" dans un dossier, puis ils fonctionnent. Dans Struts, vous devez toujours les placer dans un dossier, mais vous devez également définir un nom d'action ET un fichier JSP ET un nom de formulaire ET un bean de formulaire ET spécifier la manière dont ces trois éléments fonctionnent ensemble dans Struts-config. xml AND spécifie que le formulaire appartient à la requête (RESTful). Si cela ne suffit pas, le mappage formulaire / formulaire-bean a sa propre section dans Struts-config qui est ensuite mappée indépendamment vers la section action du même fichier. Tout repose sur des chaînes manuscrites dans le fichier JSP afin de fonctionner. correctement. Pour chaque écran, c'est au moins 6 choses que vous ne devriez pas avoir à faire et autant d'opportunités de faire une erreur. Je pense que vous pouvez définir la plupart ou la totalité de ces éléments manuellement dans Rails si vous en avez besoin, mais les 2/3 du temps de développement de Struts sont utilisés pour créer et conserver des niveaux de complexité inutiles.

En toute justice, Struts 1 a été conçu pour permettre aux utilisateurs de transférer des applications entre le poste de travail et le Web. La flexibilité avec laquelle Struts a été intégrée le rend compatible avec tout ce que fait Rails, ainsi que tout ce dont une application de bureau aurait besoin. Malheureusement, la montagne de configuration qui permet cette flexibilité est un énorme défi pour quelqu'un qui n'a besoin que d'écrire une application Web ou simplement une application de bureau.

J'ai travaillé quelque part pour passer à l'étape suivante et discuter de «Configuration sur code », mais après l'avoir vu aller à son extrême logique, le résultat est que la configuration devient un nouveau langage de codage. C'était un jeu de passe-partout où la complexité se déplaçait sans être apprivoisée de manière significative. Et cela m'a permis d'apprécier tous les contrôles de type et autres filets de sécurité qu'un langage de programmation bien conçu dispose. Un format de fichier de configuration à moitié cuit qui explose sans message d’erreur si vous ajoutez un espace ou une apostrophe n’est PAS une amélioration par rapport à un langage de programmation de qualité qui possède des suites d’outils d’édition et un compilateur de qualité écrit pour celui-ci.

Je ne peux pas imaginer que des valeurs par défaut raisonnables violent les principes théoriques d'extensibilité et de modularité. Un programmeur Ruby / Rails préfèrerait se lancer dans un poker torride plutôt que de passer à un framework tel que Struts 1, dans lequel toutes les configurations sont définies explicitement dans plusieurs fichiers XML. Je ne discute pas de Rails vs. Struts EN GÉNÉRAL, mais cette convention peut être un gain de productivité énorme. Ces deux technologies constituent la comparaison la plus extrême que j'ai rencontrée dans le monde réel.

Si vous travaillez en Java, consultez le document "Effective Java" de Joshua Bloch, élément 2: "Envisagez un générateur confronté à de nombreux paramètres de constructeur", pages 11-16. Dans la plupart des cas, certains paramètres (configuration) sont requis, et certains sont facultatifs. L'idée de base est d'exiger uniquement la configuration nécessaire et de faire en sorte que l'utilisateur (qui pourrait être un autre programme) spécifie des options supplémentaires en fonction des besoins. J'ai nettoyé un tas de code avec ce motif il y a un mois et il scintille positivement.


7

En d'autres termes, la fonctionnalité de l'application n'est pas complètement expliquée par son propre code, mais aussi par la documentation du framework.

La fonctionnalité d'une application qui utilise un framework dépend toujours du framework, la convention sur la configuration ne fait aucune différence à cet égard.

D'après mon expérience, la convention sur la configuration rend non seulement le code plus lisible, mais réduit également la possibilité d'introduire des bogues subtils (en particulier des bogues de type copier-coller).

Par exemple, supposons que dans un framework A, event FooBardéclenche un appel à handleFooBar. Dans un autre cadre B, cette corrélation est configurée quelque part dans un fichier XML.

Donc, en A, c'est simplement

handleFooBar() {
   ...
}

et à moins que FooBar soit mal orthographié, il sera appelé à chaque fois que FooBar se produit.

En B, c'est encore

handleFooBar() {
   ...
}

mais aussi

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

Avec des centaines de choses à configurer de cette façon, il est trop facile de créer accidentellement un bogue subtil comme

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

parce qu'après le copier-coller, nous avons seulement changé <type>mais nous avons oublié de changer <handler>.

Étant donné que ces fichiers de configuration sont volumineux et monotones, il est moins probable que quelqu'un trouve le bogue par correction d'épreuves qu'il le trouverait dans le code de programme réel.


1
+1: éviter les configurations répétitives, fastidieuses à écrire, difficiles à lire, presque toujours évidentes constitue le principal avantage de la configuration par convention.
Joachim Sauer le

-1

Cela enfreint peut-être peu de principes, mais en même temps, il obéit à l'un des principes de conception les plus fondamentaux, SRP (Single Responsibility Principle).


2
L'utilisation de conventions n'a rien à voir avec une responsabilité unique. Je pourrais utiliser une convention et y faire 100 choses.
Suamere
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.