Qu'est-ce qu'un logiciel d'opinion?

Je vois souvent des gens dire que certains logiciels sont "très d'opinion" ou que Microsoft a tendance à écrire des frameworks "sans opinion". Qu'est-ce que cela signifie réellement?

Si un cadre est subjectif, il verrouille ou vous guide dans leur façon de faire les choses.

Par exemple: certaines personnes croient qu'un système de modèles ne devrait pas donner accès aux méthodes et fonctions définies par l'utilisateur car il laisse le système ouvert au retour de HTML brut. Un développeur de framework avisé n'autorise donc que l'accès aux structures de données. De par sa conception, le logiciel limite et encourage le concepteur à faire les choses à sa façon.

Un autre exemple ( tiré du lien des signaux ) est celui du wiki . Les concepteurs de wiki avaient beaucoup d'opinions. Ils pensaient que le HTML était trop compliqué à écrire pour les gens, alors ils ont trouvé ce qu'ils pensaient être un moyen plus naturel de mettre à jour le contenu. Ils l'ont également dépouillé de la conception de fantaisie parce qu'ils pensaient que l'accent devrait être davantage mis sur le contenu que sur la conception.

Apple a des opinions bien arrêtées lorsqu'elle conçoit ses produits.

La conception de logiciels sans opinion ressemble plus à PERL / PHP. Il permet au développeur et lui fait confiance de prendre les bonnes décisions et met plus de contrôle entre ses mains.

Je placerais également Microsoft dans la colonne sans opinion. Un bon exemple d'un cadre de Microsoft qui est un-opininated: .NET. En ouvrant le CLR et les spécifications, il l'a ouvert à toutes sortes de langages et de styles d'implémentations.

Un logiciel avisé signifie qu'il y a fondamentalement une façon (la bonne façon ™) de faire les choses et essayer de le faire différemment sera difficile et frustrant. D'un autre côté, faire les choses de la bonne manière ™ peut faciliter le développement 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 sur le bon fonctionnement du logiciel est augmentée. Un logiciel avisé peut être excellent à utiliser, s'il est bien fait, si votre problème correspond bien à la solution. Il peut être très difficile de résoudre les parties de votre problème qui ne correspondent pas aux outils fournis. Un exemple ici serait Ruby on Rails.

Les logiciels sans opinion, en revanche, laissent beaucoup de flexibilité à l'utilisateur (développeur). Il ne proscrit pas une méthode de résolution d'un problème, mais fournit des outils flexibles qui peuvent être utilisés pour résoudre le problème de plusieurs manières. L'inconvénient de cela peut être que, comme les outils sont si flexibles, il peut être relativement difficile de développer une solution. Une plus grande partie de la solution devra peut-être être codée à la main par l'utilisateur (développeur) car le cadre ne fournit pas suffisamment d'aide. Vous devez également réfléchir beaucoup plus à la façon de fournir une solution et les développeurs médiocres peuvent se retrouver avec des solutions plus médiocres que s'ils avaient acheté un logiciel avisé. PERL est probablement l'exemple classique d'un 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 sont jugés dans une certaine mesure (mais peut-être pas 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 au sein de ces conventions. Certaines de ces façons peuvent même briser le modèle. Une utilisation correcte, cependant, conformément aux conventions qui se développent dans un tel cadre peut être une vraie joie.

C'est essentiellement un logiciel qui fonctionne comme ses auteurs pensent qu'il devrait fonctionner, 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'adoreront.

Rails est probablement l'exemple canonique d'un cadre d'opinion: vous faites les choses à leur façon, et tout est fluide. Sinon, vous aurez mal. Mais c'est OK - si vous ne voulez pas faire les choses à leur façon, vous ne voulez pas utiliser Rails.

Dans un souci d'équilibre, je fournirai une description (plutôt d'opinion) qui est plus favorable à l'approche d'opinion (contrairement à certaines des autres réponses).

Les cadres d'opinion fournissent une "voie d'or", qui est censée être la meilleure pratique pour la plupart des gens et la plupart des scénarios (aux yeux des auteurs).

Cela ne signifie cependant pas nécessairement un verrouillage. Cela signifie que cela peut exiger un effort supplémentaire pour faire les choses différemment.

Les cadres moins avisés offrent un certain nombre d'options différentes et vous laissent le soin de décider.

Les cadres d'opinion enlèvent généralement le fardeau du développeur pour réinventer la roue ou repenser le même problème encore et encore et ainsi aider à se concentrer sur le vrai problème à portée de main.

Dans le monde open-source, vous pouvez trouver de nombreux frameworks d'opinion mais concurrents, vous avez donc encore le choix. Vous n'avez qu'à choisir votre propre chemin d'or.

Le logiciel d'opinion est construit et conçu de telle manière qu'il est facile de faire les choses d'une certaine manière. Il favorise certains modèles de conception plus que d'autres. Dans le processus, 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 privilégie 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 configuration. Le logiciel avisé est généralement plus rapide à maîtriser une fois les hypothèses comprises.

En revanche, les logiciels non appréciés ne font que peu d'hypothèses. Et par conséquent, les frameworks de développement de logiciels / logiciels non exploités 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 afin de faciliter la gestion de ces énormes options. Par exemple, Visual Studio .NET pour .NET, Eclipse IDE pour Java, etc. Un logiciel non approuvé prend généralement plus de temps à maîtriser qu'un logiciel d'opinion.

tl; dr :

• Opinioned : par exemple Ruby on Rails . Il existe une façon particulièrement préférée de faire les choses, et vous obtenez beaucoup de soutien pour faire les choses de cette façon. Faire les choses autrement est difficile, voire impossible pour certains systèmes (Cassandra me vient à l'esprit).
• Sans opinion : par exemple Perl 5 . Vous pouvez faire tout 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 "non exprimé", et je voulais juste peser quelques réflexions à ce sujet.

Il est vrai que ASP.NET MVC n'exige pas trop; vous pouvez utiliser la solution de persistance que vous souhaitez, que ce soit Linq-to-SQL, ADO.NET Entities, NHibernate, etc.

D'un autre côté, le framework MVC a tendance à 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 entoure également beaucoup de gens d'opinion, ce qui, à mon avis, conduit à de nombreux didacticiels biaisés qui insistent sur la couverture, par exemple les tests unitaires et l'injection de dépendances; Je suis pour de bons tests et une séparation des préoccupations, mais je perçois que de tels sujets sont poussés un peu dans la gorge, souvent avant de couvrir des bases plus utiles.

Là encore, je dois admettre que dans ces domaines, le cadre lui-même est complètement ouvert à l'adoption de la solution de test unitaire que vous souhaitez, ainsi que des cadres d'injection de dépendance et de simulation que vous souhaitez utiliser, donc je suppose que cela fournit un autre exemple de la flexibilité, même dans le «dénigrement de la Bible» des tests unitaires, etc. qui semble être en cours.

C'est le nombre de conventions mises en œuvre dans un cadre et le nombre de décisions qui ont été prises.

Si, par exemple, il existe 5 (ou plus) façons 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 en place à toi!

Si, cependant, le cadre autorise (soit en désactivant directement d'autres moyens, soit en l'encourageant fortement) une seule façon de faire cette chose (ce qui est le cas avec Fubu MVC), vous pourriez dire que la décision a été prise par le cadre , rendant ainsi le cadre formulé.

L'exemple que vous verrez beaucoup en ce moment est le framework ASP.NET MVC. Il est incroyablement extensible, mais c'est sa chute à certains égards, il n'y a pas de viande. Vous souhaitez accéder aux données? Vous devrez l'écrire vous-même. Vous voulez de l'AJAX? Idem.

Cependant, comme il est très extensible, si vous le construisez, vous pouvez le transformer en un cadre d'opinion. C'est ce que font MVCContrib , 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 vous écarter de l'opinion, il y a souvent plus de travail à faire que si vous travailliez sur la version vanille. Il s'agit cependant d'un scénario 80/20. Si vous choisissez correctement votre cadre d'opinion, vous ne voudrez rompre avec les opinions que 20% du temps et vous serez très productif les 80% restants.