Qu'est-ce qu'un logiciel d'opinion?
Je vois souvent des gens dire que certains logiciels sont "très opinions" ou que Microsoft a tendance à écrire des frameworks "sans opinion". Qu'est-ce que cela signifie réellement?
Si un cadre fait l’objet d’une opinion, il vous verrouille ou vous guide dans sa manière de faire les choses.
Par exemple: certaines personnes pensent qu'un système de modèle ne devrait pas fournir d'accès aux méthodes et fonctions définies par l'utilisateur, car il laisse le système ouvert au renvoi de code HTML brut. Ainsi, un développeur de framework avisé n'autorise que l'accès aux structures de données. De par sa conception, le logiciel limite et encourage le concepteur à faire les choses à sa manière.
Un autre exemple ( tiré du lien de signaux ) est celui de wiki . Les concepteurs de wiki avaient beaucoup d'opinions. Ils pensaient que le langage HTML était trop compliqué à écrire pour les utilisateurs. Ils ont donc proposé ce qu'ils pensaient être un moyen plus naturel de mettre à jour le contenu. Ils ont également supprimé le design sophistiqué car ils ont estimé que l'accent devrait être mis davantage sur le contenu que sur le design.
Apple a de fortes opinions lorsqu'il conçoit ses produits.
Conception de logiciel sans opinion ressemble plus à Perl/PHP. Il permet au développeur et lui fait confiance de prendre les bonnes décisions et leur donne plus de contrôle.
Je voudrais également placer Microsoft dans la colonne sans opinion. Un bon exemple de framework Microsoft non-opininciné: .NET. En ouvrant le CLR et les spécifications, il s’est ouvert à toutes sortes de langages et de styles d’implémentation.
Un logiciel d'opinion signifie qu'il y a fondamentalement un moyen (le bon moyen ™) de faire les choses et essayer de le faire différemment sera difficile et frustrant. Par contre, faire les choses à la manière bonne manière ™ peut être très facile à développer avec le logiciel, car le nombre de décisions que vous devez prendre est réduit et la capacité des concepteurs de logiciels à se concentrer le travail du logiciel est augmenté. Le logiciel Opinionated peut être intéressant à utiliser, si cela est bien fait, si votre problème correspond parfaitement à la solution. Il peut être très pénible de résoudre les parties de votre problème qui ne correspondent pas aux outils fournis. Un exemple ici serait Ruby sur Rails.
Les logiciels sans opinion, en revanche, offrent beaucoup de flexibilité à l'utilisateur (développeur). Il n'interdit pas une méthode de résolution de problème, mais fournit des outils flexibles pouvant être utilisés pour résoudre le problème de nombreuses manières. L'inconvénient est que, vu la flexibilité des outils, il peut être relativement difficile de développer une solution. Une grande partie de la solution devra peut-être être codée à la main par l'utilisateur (développeur), car la structure ne fournit pas assez d'aide. Vous devez également penser beaucoup plus à la manière de fournir une solution, et les développeurs médiocres risquent de se retrouver avec des solutions plus médiocres que s'ils avaient acheté un logiciel avisé. Perl est probablement l'exemple classique du logiciel sans opinion.
Mon idéal est un cadre sans opinion, mais avec des conventions fortes. Je mettrais ASP.NET MVC dans cette catégorie. En réalité, tous les logiciels font l’objet d’une opinion dans une certaine mesure (mais peut-être pas de Perl). MVC a des conventions fortes dans son choix de modèle mais offre de nombreuses façons différentes de résoudre les problèmes relevant de ces conventions. Certaines de ces méthodes peuvent même casser le modèle. Bien utilisé, cependant, conformément aux conventions développées dans un tel cadre, peut être une vraie joie.
Il s’agit essentiellement d’un logiciel qui fonctionne de la manière dont les auteurs le pensent, au lieu d’essayer de plaire à tout le monde. Cela signifie que beaucoup de gens ne l'aimeront pas, mais ceux qui le feront l'aimeront.
Rails est probablement l'exemple canonique d'un cadre d'opinion: vous faites les choses à leur manière et tout se passe bien. Si vous ne le faites pas, vous allez souffrir. Mais ce n'est pas grave - si vous ne voulez pas faire les choses à leur manière, vous ne voulez pas utiliser Rails.
Par souci d'équilibre, je fournirai une description (plutôt opinionée) plus favorable à l'approche exprimée (contrairement à certaines des autres réponses).
Les cadres d'opinion fournissent un "sentier d'or", qui est supposé être la meilleure pratique pour la plupart des gens et la plupart des scénarios (aux yeux des auteurs).
Cela ne signifie toutefois pas nécessairement un verrouillage. Cela signifie que des efforts supplémentaires peuvent être nécessaires pour faire les choses différemment.
Les cadres moins d'opinion offrent un certain nombre d'options différentes et vous laissent le choix.
Les frameworks d'opinion soulagent généralement le développeur de réinventer la roue ou de repenser le même problème encore et encore et aident ainsi à se concentrer sur le vrai problème.
Dans le monde des logiciels libres, vous pouvez trouver de nombreux frameworks à la fois opposés et opinions, de sorte que vous avez toujours le choix. Vous devez juste choisir votre propre chemin en or.
Le logiciel Opinionated est construit et conçu de manière à faciliter les choses d'une certaine manière. Il favorise certains modèles de conception plus que d'autres. Ce faisant, il est difficile de s’écarter du style de développement logiciel pour lequel il a été développé. Une autre façon de le dire est qu'il favorise la "Convention sur la configuration". C'est-à-dire que les options de configuration sont très limitées car le logiciel assume de nombreux aspects de la configuration. Les logiciels d’opinion sont généralement plus rapides à maîtriser une fois que les hypothèses sont bien comprises.
Un logiciel non prévu, en revanche, repose sur peu d'hypothèses. Et, par conséquent, les infrastructures de développement de logiciels/logiciels qui n’ont pas été approuvées ont souvent tendance à avoir beaucoup d’options de configuration. Un développeur doit généralement prendre de nombreuses décisions concernant divers aspects du logiciel. Souvent, divers outils sont développés pour faciliter la gestion de ces énormes options. par exemple. Visual Studio .NET pour .NET, Eclipse IDE pour Java etc. Les logiciels non accompagnés prennent généralement plus de temps à maîtriser que les logiciels avec opinion.
tl; dr:
- Opinionated: par ex. Ruby on Rails . Il y a une façon particulièrement préférée de faire les choses et vous obtenez beaucoup de soutien pour le faire. Faire les choses autrement est difficile, voire impossible pour certains systèmes (on pense à Cassandra).
- sans opinion: par ex. Perl 5 . Vous pouvez faire ce que vous voulez, comme vous le souhaitez, dans n'importe quel style. Tous les styles sont également ouverts, valides et pris en charge.
Beaucoup de gens font référence à ASP.NET MVC en tant que framework "sans opinion", et je voulais juste faire quelques réflexions à ce sujet.
Il est vrai qu'ASP.NET MVC n'exige pas beaucoup de mandat. vous pouvez utiliser la solution de persistance de votre choix, qu’il s’agisse de Linq-to-SQL, d’entités ADO.NET, de NHibernate, etc.
D'un autre côté, le framework MVC tend à favoriser la "convention sur la configuration", pour citer Phil Haack, qui suggère fortement de suivre le modèle prédéfini pour localiser les contrôleurs, les vues, les modèles et autres codes. Bien que vous puissiez modifier ce comportement, il est plus facile de nager avec le courant, et pour la plupart des gens, cela ne pose aucun problème.
ASP.NET MVC englobe également un grand nombre de personnes qui ont une opinion, ce qui, à mon avis, conduit à de nombreux tutoriels biaisés qui exigent une couverture, par exemple. tests unitaires et injection de dépendance; Je suis tout à fait d'accord pour bien tester et séparer les préoccupations, mais je me rends compte que de tels sujets sont un peu enfouis dans la gorge, souvent avant même de couvrir des bases plus utiles.
Là encore, je dois admettre que, dans ces domaines, le framework lui-même est tout à fait ouvert à l’adoption de la solution de test unitaire de votre choix, ainsi que des frameworks d’injection de dépendance et de moquage que vous souhaitez utiliser. la flexibilité, même dans le cadre du "déni de bible" des tests unitaires, etc. qui semble se poursuivre.
C'est le nombre de conventions mises en œuvre dans un cadre et le nombre de décisions prises.
Si, par exemple, il existe 5 façons (ou plus) différentes de soumettre des données de formulaire à une action de contrôleur (ce qui est le cas dans ASP.NET MVC), le cadre semble être assez "sans opinion" - la décision est prise à toi!
Si, toutefois, le cadre ne permet (soit en désactivant directement d’autres moyens, soit en l’encourageant fortement) qu’un seul moyen de le faire (ce qui est le cas avec Fubu MVC), vous pouvez dire que la décision a été prise par le cadre. , rendant ainsi le cadre avisé.
L'exemple que vous verrez beaucoup en ce moment est le framework ASP.NET MVC. Il est étonnamment extensible, mais c'est sa chute à certains égards, il n'y a pas de viande à elle. Voulez-vous faire un accès aux données? Vous devrez écrire cela vous-même. Vous voulez qu'il en reste AJAX? Idem.).
Cependant, comme il est hautement extensible, vous pouvez le transformer en un cadre basé sur l'opinion si vous le construisez. C’est ce que les gens comme MVCContrib font, ils vous donnent des méthodes spécifiques pour faire les choses, ce qui signifie que vous devez écrire moins de code.
Cela signifie que si vous voulez rompre avec l'opinion, il vous reste souvent beaucoup de travail à faire par rapport à la version Vanilla. Ceci est un scénario 80/20 cependant. Si vous avez choisi votre cadre d'opinion correctement, vous ne voudrez vous séparer de l'opinion que 20% du temps et vous serez très productif les 80% restants.