¿Qué es el software obstinado?

El software obstinado significa que básicamente hay una manera (la manera correcta™) de hacer las cosas y tratar de hacerlo de manera diferente será difícil y frustrante. Por otro lado, hacer las cosas de la manera correcta ™ puede hacer que sea muy fácil de desarrollar con el software, ya que el número de decisiones que tiene que tomar se reduce y la capacidad de los diseñadores de software para concentrarse en hacer que el software funcione se incrementa. El software obstinado puede ser genial de usar, si se hace bien, si su problema se asigna a la solución muy bien. Puede ser un verdadero dolor para resolver aquellas partes de su problema que no se asignan a las herramientas proporcionadas. Un ejemplo aquí sería Ruby on Rails.

El software no obstinado, por otro lado, deja mucha flexibilidad al usuario (desarrollador). No proscribe un método para resolver un problema, pero proporciona herramientas flexibles que se pueden usar para resolver el problema de muchas maneras. La desventaja de esto puede ser que porque las herramientas son tan flexible, puede ser relativamente difícil desarrollar cualquier solución. Mucho más de la solución puede tener que ser codificado a mano por el usuario (desarrollador) porque el marco no proporciona suficiente ayuda. También tienes que pensar mucho más sobre cómo proporcionar una solución y los desarrolladores mediocres pueden terminar con soluciones más pobres que si hubieran comprado algún software obstinado. PERL es probablemente el ejemplo clásico de software no obstinado.

Mi ideal es un marco no obstinado, pero uno con fuertes convenciones. Yo pondría ASP.NET MVC en esta categoría. En realidad todo el software es opinionated hasta cierto punto (aunque quizás no PERL). MVC tiene fuertes convenciones en su elección de modelo, pero ofrece muchas formas diferentes de resolver problemas dentro de esas convenciones. Algunas de esas formas pueden incluso romper el modelo. Utilizado correctamente, sin embargo, de acuerdo con las convenciones que se desarrollan en un marco de este tipo puede ser una verdadera alegría.

Básicamente es software que funciona de la manera en que sus autores piensan que debería funcionar, en lugar de tratar de complacer a todos. Eso significa que a mucha gente no le gustará, pero a los que sí les encantará.

Rails es probablemente el ejemplo canónico de un framework obstinado: haces las cosas a su manera, y todo es suave. Si no lo haces, te espera un poco de dolor. Pero está bien if si no quieres hacer las cosas a su manera, no quieres usar Rails.

Por el bien del equilibrio proporcionaré una descripción (bastante opinionada) que es más favorable al enfoque opinionated (en contraste con algunas de las otras respuestas).

Los marcos opinionated proporcionan un "camino de oro", que se supone que es la mejor práctica para la mayoría de las personas y la mayoría de los escenarios (a los ojos de los autores).

Sin embargo, esto no significa necesariamente bloqueo. Significa que puede requerir un esfuerzo adicional para hacer las cosas de manera diferente.

Menos obstinado los marcos proporcionan una serie de opciones diferentes y dejan que usted decida.

Los frameworks obstinados generalmente eliminan la carga del desarrollador para reinventar la rueda o repensar el mismo problema una y otra vez y así ayudar a enfocarse en el problema real en cuestión.

En el mundo del código abierto puede encontrar muchos marcos obstinados pero competitivos, por lo que todavía tiene una opción. Solo tienes que elegir tu propio camino dorado.

El software de opinión está construido y diseñado de tal manera que hace que sea fácil hacer las cosas de cierta manera. Favorece ciertos patrones de diseño más que otros. En el proceso, hace que sea difícil desviarse del estilo de desarrollo de software para el que fue desarrollado. Otra forma de decirlo es que favorece la "Convención sobre la configuración". es decir, las opciones de configuración son muy limitadas ya que el software asume muchos de los aspectos de configuración. Software de opinión por lo general es más rápido de dominar una vez que se entienden las suposiciones.

El software no opinado, por otro lado, hace pocas suposiciones. Y como resultado, los marcos de desarrollo de software/software que no están definidos a menudo tienden a tener muchas opciones de configuración. Un desarrollador normalmente tiene que tomar muchas decisiones con respecto a varios aspectos del software. A menudo, se desarrollan varias herramientas para facilitar el manejo de estas enormes opciones. por ejemplo, Visual Studio. NET para. NET, Eclipse IDE para Java, etc. El software no opinionated toma típicamente más de largo dominar que el software opinionated.

Tl; dr :

• Obstinado: por ejemplo, Ruby on Rails. Hay una forma particularmente preferida de hacer las cosas, y obtienes mucho apoyo para hacer las cosas de esa manera. Hacer las cosas de otras maneras es difícil, o para algunos sistemas imposible (Cassandra viene a la mente).
• Un-opinionated: e.g. Perl 5. Puedes hacer lo que quieras, como quieras, en cualquier estilo. Todos los estilos son igualmente abiertos, válidos y compatibles.

Mucha gente está haciendo referencia ASP.NET MVC como un marco "no opinado", y solo quería opinar con un par de pensamientos sobre eso.

Es cierto que ASP.NET MVC no exige demasiado; puede usar cualquier solución de persistencia que desee, ya sea Linq-to-SQL, ADO.NET Entidades, NHibernate, etc.

Por otro lado, el framework MVC tiende a favorecer la "convención sobre la configuración", para citar a Phil Haack, que sugiere en gran medida seguir el patrón predefinido para localizar controladores, vistas, modelos y otro código. Aunque puedes alterar este comportamiento, es más fácil nadar con la corriente, y para la mayoría de las personas, no hay problema en hacerlo.

También alrededor ASP.NET MVC son muchas personas obstinadas, lo que me parece conduce a una gran cantidad de tutoriales sesgados que insisten en cubrir, por ejemplo, pruebas unitarias e inyección de dependencia; estoy a favor de una buena prueba y separación de preocupaciones, pero percibo que tales temas se meten en la garganta de uno poco, a menudo por delante de cubrir los conceptos básicos más útiles.

Una vez más, tengo que admitir que dentro de esas áreas, el marco en sí está completamente abierto a adoptar cualquier solución de prueba unitaria que desee, así como cualquier inyección de dependencia y marcos de burla que desee usar, así que supongo que eso proporciona otro ejemplo de flexibilidad, incluso dentro del "golpe bíblico" de las pruebas unitarias, etc. eso parece estar sucediendo.

Es la cantidad de convenciones implementadas en un framwork y el número de decisiones que se han tomado.

Si, por ejemplo, hay 5 (o más) formas diferentes de enviar datos de formulario a una acción del controlador (que es el caso en ASP.NET MVC), el marco parece ser bastante "sin opiniones" - ¡la decisión depende de ti!

Si, sin embargo, el framework habilita (ya sea deshabilitando directamente otras formas, o alentándolo fuertemente) solo una forma de hacer eso (que es el caso de Fubu MVC), se podría decir que la decisión ha sido tomada por el marco, lo que hace que el marco sea dictaminado.

El ejemplo que verá mucho en este momento es el ASP.NET Marco MVC. Es increíblemente extensible, pero esa es su caída en algunos aspectos, no hay carne en él. ¿Quieres acceder a los datos? Tendrás que escribirlo tú mismo. ¿Quieres un poco de AJAX? Ídem.

Sin embargo, como es altamente extensible, si construyes sobre él puedes convertirlo en un framework obstinado. Esto es lo que hacen los gustos de MvcContrib, te dan métodos específicos de hacer las cosas, lo que significa tienes que escribir menos código.

Esto significa que si desea romper con la opinión, a menudo hay más trabajo que hacer que si estuviera trabajando en la versión vainilla. Sin embargo, este es un escenario 80/20. Si elegiste correctamente tu marco de opinión, solo querrás romper con las opiniones el 20% del tiempo y serás altamente productivo el otro 80% del tiempo.