Qu'est-ce que opiniâtre logiciel?

Un logiciel opiniâtre 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'autre part, faire les choses de la bonne façon ™ peut le rendre 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 sur le travail du logiciel est augmentée. Un logiciel opiniâtre peut être génial à utiliser, s'il est bien fait, si votre problème correspond bien à la solution. Cela peut être une vraie douleur 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 Non opiniâtres, d'autre part, laissent beaucoup de flexibilité à l'utilisateur (développeur). Il n'est pas interdit 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 façons. L'inconvénient de cela peut être que parce que les outils sont si flexible, il peut être relativement difficile de développer une solution. Beaucoup plus de la solution peut devoir être codée à la main par l'utilisateur (développeur) parce que le framework ne fournit pas assez d'aide. Vous devez également penser beaucoup plus sur la façon de fournir une solution et les développeurs médiocres peuvent se retrouver avec des solutions plus pauvres que s'ils avaient acheté dans un logiciel opiniâtre. PERL est probablement l'exemple classique de logiciel non opiniâtre.

Mon idéal est un cadre non opiniâtre, mais un avec des conventions fortes. Je mettrais ASP.NET MVC dans cette catégorie. En réalité, tous les logiciels sont opiniâtres 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. Certains de ces moyens peuvent même briser le modèle. Utilisé correctement, cependant, conformément aux conventions se développant 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'aimeront.

Rails est probablement l'exemple canonique d'un framework opiniâtre: vous faites les choses à leur façon, et tout est lisse. Si vous ne le faites pas, vous êtes dans la douleur. Mais c'est OK-si vous ne voulez pas faire les choses à leur façon, vous ne voulez pas utiliser Rails.

Par souci d'équilibre, je vais fournir une description (plutôt opiniâtre) qui est plus favorable à l'approche opiniâtre (contrairement à certaines des autres réponses).

Les cadres opiniâtres fournissent un "chemin d'or", qui est censé ê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 nécessiter un effort supplémentaire pour faire les choses différemment.

Moins opiniâtre les cadres offrent un certain nombre d'options différentes et vous laissent le soin de décider.

Les frameworks opiniâtres suppriment 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 opiniâtres mais concurrents, donc vous avez toujours le choix. Vous avez juste à choisir votre propre chemin doré.

Le logiciel Opinionated est construit et conçu de telle sorte qu'il facilite 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 mettre 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. Logiciel opiniâtre habituellement est plus rapide à maîtriser une fois que les hypothèses sont comprises.

Les logiciels Non consultés, d'autre part, font peu d'hypothèses. Et par conséquent, les frameworks de développement de logiciels/logiciels qui ne sont pas consultés ont souvent tendance à avoir beaucoup d'options de configuration. Un développeur doit généralement prendre beaucoup de décisions concernant divers aspects du logiciel. Souvent, divers outils sont développés afin de faciliter le traitement de ces énormes options. par exemple Visual Studio. Net pour. NET, Eclipse IDE pour Java etc. Les logiciels non consultés prennent généralement plus de temps à maîtriser que les logiciels opiniâtres.

Tl;dr:

• Opiniâtre: par exemple 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 faire les choses de cette façon. Faire les choses d'autres façons est difficile, ou pour certains systèmes impossible (Cassandra vient à l'esprit).
• Onu-opiniâtre: par exemple Perl 5. Vous pouvez faire ce que vous voulez, comme vous voulez, 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 cadre "sans opinion", et je voulais juste peser avec quelques réflexions à ce sujet.

C'est vrai que ASP.NET MVC ne mandate pas trop; vous pouvez utiliser la solution de persistance que vous aimez, que ce soit Linq-to-SQL, ADO.NET entités, NHibernate, etc.

D'un autre côté, le framework MVC a tendance à privilégier 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, vues, 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, il n'y a pas de problème à le faire.

Également entourant ASP.NET MVC sont beaucoup de gens opiniâtres, que je trouve conduit à beaucoup de tutoriels biaisés qui insistent sur la couverture, par exemple les tests unitaires et l'injection de dépendance; je suis tout pour de bons tests et la séparation des préoccupations, mais je perçois que de tels sujets sont poussés dans la gorge peu, souvent en avance sur les bases plus utiles.

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

C'est la quantité de conventions implémentées dans un framwork 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 à vous!

Si, cependant, le framework permet (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 opiniâtre.

L'exemple que vous verrez beaucoup en ce moment est le ASP.NET cadre MVC. Il est étonnamment extensible mais c'est sa chute à certains égards, il n'y a pas de viande à elle. Souhaitez faire de l'accès aux données? Vous devez écrire vous-même. Voulez AJAX se passe? Idem.

Cependant, comme il est hautement extensible, si vous construisez dessus, vous pouvez le transformer en un cadre opiniâtre. C'est ce que font les gens de MVCContrib, ils vous donnent des méthodes spécifiques pour faire les choses, ce qui signifie vous devez écrire moins de code.

Cela signifie que si vous voulez rompre avec l'opinion, il y a souvent plus de travail à faire que si vous travailliez sur la version vanilla. C'est un scénario 80/20 cependant. Si vous avez choisi correctement votre cadre opiniâtre, vous ne voudrez que rompre avec les opinions 20% du temps et vous serez très productif l'autre 80% du temps.