¿Los marcos ponen demasiada abstracción? [cerrado]

He estado programando durante poco menos de un año y tengo algo de experiencia escribiendo aplicaciones de sistemas, aplicaciones web y scripts para empresas / organizaciones. Sin embargo, una cosa que nunca he hecho realmente es trabajar con un framework como Django, Rails o Zend.

Mirando el marco de Django, estoy un poco frustrado con la cantidad de marcos abstraídos. Entiendo los objetivos centrales de DRY y el código mínimo, pero parte de esta dependencia excesiva en diferentes módulos y una gran abstracción de las funciones centrales se siente así:

1. Hace que los programas tengan una fecha realmente rápida debido a la naturaleza cambiante de los módulos / marcos,

2. Hace que el código sea difícil de entender debido a la gran cantidad de marcos y módulos disponibles y todas sus idiosincrasias,

3. Hace que el código sea menos lógico a menos que haya leído toda la documentación; es decir, puedo leer algunas comprensiones de listas y lógica condicional y descubrir qué está haciendo un programa, pero cuando ves funciones que requieren pasar cadenas y diccionarios arbitrarios, las cosas se vuelven un poco difíciles de entender a menos que ya seas un gurú en un módulo dado; y:

4. Hace que sea difícil y tedioso cambiar entre marcos. Cambiar de idioma ya es un desafío, pero es manejable si tienes una comprensión lo suficientemente sólida de su funcionalidad / filosofía central. Cambiar entre marcos parece ser más una cuestión de memorización memorística, que de alguna manera parece alentar la ineficiencia que estos marcos fueron diseñados para eliminar.

¿Realmente necesitamos poner como 50 capas de abstracción sobre algo tan simple como una consulta MySQL? ¿Por qué no usar algo como la interfaz PDO de PHP, donde las declaraciones preparadas / pruebas de entrada se manejan pero la consulta SQL universalmente comprensible todavía es parte de la función?

¿Son realmente útiles esas abstracciones? ¿La hinchazón de características no las hace inútiles y hace que las aplicaciones sean más difíciles en comparación con aplicaciones similares escritas sin usar un marco?

Los marcos pueden ser realmente difíciles. Los problemas pueden surgir fácilmente cuando un marco es demasiado "obstinado", es decir, cuando realmente prefiere un estilo particular de aplicación y todas las partes están orientadas a soportar este estilo particular.

Por ejemplo, si el marco abstrae completamente el proceso de autenticación de un usuario al permitirle agregar un solo componente, agregar una plantilla de inicio de sesión en algún lugar y listo, obtendrá la autenticación de usuario de forma gratuita. Esto le ahorró mucho trabajo repetitivo al preocuparse por las cookies, el almacenamiento de sesiones, el hash de contraseñas y otras cosas.

Los problemas comienzan cuando te das cuenta de que el comportamiento predeterminado del código de autenticación del marco no es lo que necesitas. Quizás no esté siguiendo las últimas mejores prácticas de seguridad. Quizás necesite un enlace personalizado en el proceso para activar alguna acción, pero el marco no ofrece uno. Tal vez necesite cambiar los detalles de la cookie que se está configurando, pero el marco no ofrece ninguna forma de personalizarlo.

La abstracción ofrecida por el marco le permitió agregar una característica importante a su sitio en cuestión de minutos en lugar de días inicialmente, pero al final puede que tenga que luchar contra el marco para que haga lo que necesita que haga, o de lo contrario tiene que reinventar la funcionalidad desde cero nuevamente de todos modos para satisfacer sus necesidades.

Esto no quiere decir que las abstracciones del marco sean malas, eso sí. Es decir que esta es siempre una posibilidad que debe tener en cuenta. Algunos marcos están orientados explícitamente a esto, ofrecen una manera de obtener algo muy rápidamente como prototipo o incluso marco de producción para un tipo de aplicación muy específico y limitado. Otros marcos son más como colecciones sueltas de componentes que puede usar, pero que aún le permiten mucha flexibilidad para cambiarlo más adelante.

Al usar una abstracción, siempre debe comprender al menos aproximadamente lo que está abstrayendo. Si no comprende las cookies y los sistemas de autenticación, comenzar desde una abstracción no es una buena idea. Si entiendes lo que estás tratando de hacer y solo necesitas un código que ya lo hace en lugar de tener que escribir tediosamente el tuyo, las abstracciones son un gran ahorro de tiempo. Sin embargo, las abstracciones mal escritas pueden meterte en problemas más tarde, por lo que es una espada de doble filo.

También debe distinguir entre abstracciones técnicas y abstracciones de "reglas comerciales" . La programación en un lenguaje de nivel superior es una abstracción que probablemente no quiera perderse (Python, PHP, C # vs. C vs. Assembler; Less vs. CSS), mientras que las "abstracciones de reglas de negocios" pueden ser difíciles si no lo hacen. satisfaga exactamente sus necesidades (autenticación con un solo clic frente a cookies de codificación manual).

Esto se debe a que las abstracciones técnicas rara vez se "filtran", es decir, difícilmente tendrá que depurar el código de la máquina al escribir aplicaciones en Python. Sin embargo, las abstracciones de reglas de negocio funcionan en el mismo nivel técnico y en realidad son solo "paquetes de código". Es probable que se necesita depurar la cookie que se establece o el hash de la contraseña que se crea en algún momento, lo que significa que será buceo a través de un montón de código de tercera parte.

Me parece que no entiendes las abstracciones y la reutilización del código.

Toda la industria de desarrollo de software se basa en abstracciones. El hecho de no usarlos, es decir, evitar el uso de frameworks, bibliotecas y, en general, código que no está escrito internamente, aumentaría el costo que necesita para producir un software en cientos, miles, probablemente incluso más.

Al igual que no crea un avión jumbo desde cero, sin utilizar ningún conocimiento de ingeniería desarrollado durante años al construir otras aeronaves, no escribe software empresarial desde cero.

En primer lugar, obtienes eso usando PHP o Ruby, ya tienes una gran cantidad de abstracciones, ¿verdad? Los más obvios:

1. El sistema operativo, el lenguaje de programación y el compilador proporcionan una gran abstracción sobre Assembler y hardware,

2. El servidor web proporciona una abstracción de sockets, failover, protocolo HTTP, etc.

3. SQL proporciona una abstracción sobre cómo se almacenan los datos en un soporte de almacenamiento permanente y se mantienen en la memoria para un acceso más rápido, asegura ACID, duplicación, etc.

Siempre puede intentar crear una aplicación web sin utilizar un sistema operativo, un servidor web, una base de datos o un lenguaje de programación de alto nivel. Rápidamente descubrirá que pasó años reinventando la rueda, es decir, recreando su lenguaje de programación, su servidor web y su base de datos, dado que su calidad estaría muy lejos de la calidad de los productos que realmente utilizamos.

Los marcos no son diferentes de eso. Puedes hacer lo que ellos hacen. Solo que perderá su tiempo rehaciendo la misma funcionalidad, con la diferencia de que esos marcos lo harán mejor y muy a menudo su código será probado y documentado mejor que el suyo.

Tome el ejemplo de un carrito para un sitio web de comercio electrónico. Puedes inventar el tuyo y pasar unas semanas desarrollándolo, o puedes tomar el que fue desarrollado durante años por un grupo de personas dentro de un marco. Se espera que prueben los suyos, sin contar el hecho de que durante unos años, esos desarrolladores descubrieron y repararon un montón de errores que no imaginarán al desarrollar su propio carrito.

Puede responder que el suyo es más complicado porque tiene más casos de usuario. Por ejemplo, los suyos deben tratar con reembolsos, mientras que usted no tiene reembolsos en su sitio web y no necesita esta función en el carrito. Bueno, no está obligado a usar esta función, y no es que penalice el rendimiento de su aplicación web.

Es posible que tenga un escenario muy básico cuando es realmente más fácil desarrollar su propio carro en lugar de usar el existente. Del mismo modo, si lo único que necesita su aplicación es almacenar una lista de números, nada más, no necesita una base de datos: un simple relleno de texto sería suficiente. En esos casos, no sobre-ingenie su aplicación: los escenarios simples requieren soluciones simples.

Otro factor es la legibilidad de su código. Imagine que ha creado un sitio web de comercio electrónico. Más tarde, dejó el proyecto y otro desarrollador debería mantenerlo.

• Si hubiera utilizado un carrito proporcionado por un marco, su colega se sentiría aliviado: debe mantener un pequeño código que se base en un marco confiable y muy documentado. Aún mejor: este desarrollador puede haber sido utilizado para trabajar con este marco y le es familiar. Si no, puede hacer preguntas sobre Stack Overflow: seguro, alguien ya ha usado el marco.

• Si tuviera su propio carrito, entonces su colega tendría que mantener un código personalizado, tal vez ni siquiera documentado, sin poder obtener ayuda en ningún lado.

Al usar un marco, confía en un código que es:

• Escrito por desarrolladores experimentados,

• A menudo revisado por pares,

• Probado en la unidad,

• Ampliamente documentado,

• Usado durante años por miles de desarrolladores,

• A menudo es compatible, por lo que puede informar un error y verlo realmente solucionado,

• Conocido por muchos desarrolladores que conocen las posibles advertencias y problemas y pueden ayudar en sitios como Stack Overflow.

• Disponible para usted en este momento, de forma gratuita.

Estoy de acuerdo: la mayoría de los marcos se convierten en dictadores inflados. Prometen libertad pero terminas en servidumbre. mire un marco como una herramienta: la mejor herramienta es la que se mantiene fuera de su camino. Si en PHP sugiero que revise el marco de Codeigniter, porque es un elegante equilibrio entre convenciones y libertad y tiene una gran comunidad. Y para el afiche que utilizó el ejemplo de un carrito de comercio electrónico, me gustaría poder estar de acuerdo con usted. pero después de haber examinado el código de muchas soluciones de comercio electrónico, y diseñado algunas, no estoy de acuerdo respetuosamente con su ejemplo.

Hmmm Un aspecto de LedgerSMB en el que trabajamos mucho fue nuestro enfoque del framework. Sin embargo, hay dos problemas fundamentales que vienen con este tipo de abstracción. Estos son:

1. Explosión de dependencia, y

2. Abstracción equivocada

El primero es en realidad mejor que la alternativa que es reinventar la rueda. El segundo es un poco difícil de etiquetar porque puede provenir de un caso de problema mal definido o, más a menudo, de personas que usan algo fuera de su uso previsto.

Veamos ORM por ejemplo. Evito usar ORM porque es muy frecuente que el db termine diseñado para el modelo de objetos de la aplicación porque, en el mejor de los casos, son capas de abstracción con fugas. Este no es necesariamente el caso. Me he reunido con desarrolladores que logran preservar un buen diseño de base de datos y una buena aplicación mientras usan ORM, pero recurren a muchas cosas que la exageración de orm dice que no deberían ser necesarias, como encapsular la API relacional de la base de datos detrás de las vistas actualizables.

Un problema importante, por supuesto, es que cuanto más altamente automatizado sea el código, particularmente cuando también es opaco, más difícil será ver qué va mal. Este es un punto sobre los ORM que @jhewlett hace arriba (consulte /software//a/190807/63722 ).

Un buen paralelo podría ser la aviónica avanzada como marco para pilotar una aeronave. Estos han sido altamente diseñados para la fiabilidad y son un factor en el aumento de la seguridad de vuelo. Sin embargo, como muchos artículos en IEEE Spectrum señalan, esto tiene un costo de recuperación de errores fuera de los límites de lo que se considera aceptable desde una perspectiva de automatización. Lo mismo ocurre con la depuración. Una cosa es depurar el código SQL en su programa. Es muy diferente depurar una parte de su programa que escribe código SQL para que su programa lo use.

Escribimos el marco LedgerSMB desde cero porque en el momento en que comenzamos, no había marcos realmente buenos que hicieran lo que queríamos. En realidad, es algo con lo que estoy bastante contento, y según un desarrollador más nuevo en el proyecto, hace que la personalización de la aplicación sea bastante sencilla. (En realidad, mantenemos la generación de código SQL al mínimo y, en cambio, nos centramos en las funciones definidas por el usuario escritas a mano, lo que significa que las porciones de escritura SQL son muy delgadas). Sí, proporciona mucha abstracción en algunos lugares, más de lo que algunos programadores se sienten cómodos (en particular, "asignar propiedades de objetos a argumentos en ese procedimiento almacenado" nos hace retroceder de vez en cuando). Sin embargo, tratamos de mantener todo simple y consistente para que sea sencillo determinar qué salió mal. Esto funciona bastante bien.

Al final, "demasiado" es un poco subjetivo, pero a nivel objetivo también depende de lo que esté haciendo. Si está haciendo exactamente para lo que fue diseñado el marco, un marco bien diseñado proporcionará una cantidad perfecta de abstracción. Si está haciendo algo que encaja un poco menos, la abstracción se volverá demasiado y demasiado permeable.

Sí, son útiles. Le proporcionan el beneficio de muchos otros desarrolladores experimentados que trabajan para resolver un problema que necesita resolver, con los beneficios adicionales de haberlo probado, corregido muchos errores y proporcionado soluciones a problemas difíciles de los que no tiene que preocuparse. usted mismo utilizando el marco.

¿Pueden ser hinchados excesivamente? Seguro. Todo esto depende de lo que necesita y de lo que el marco trae a la mesa. Si tiene una aplicación web simple, tal vez Rails sea excesivo para usted, y debería considerar algo más simple como Sinatra como solución.

Definitivamente hay una curva de aprendizaje para todos los marcos, y es más pronunciada con más trabajo que ahorra para usted. Sin embargo, aprender el marco significa que ha ahorrado tiempo y puede aprovechar todo ese conocimiento en el próximo proyecto, en lugar de reescribir su aplicación desde cero, una segunda vez.

Pero, dices, simplemente copiaré mi código del proyecto anterior, ¡y puedo usarlo como punto de partida para mi nuevo proyecto! Solo cambiaré lo que es diferente, y tal vez haga que algunos de mis objetos / funciones sean más generales, ¡y piense en una mejor manera de resolver ese código complicado! Felicitaciones, acabas de crear un marco. Haga esto miles de veces más, y tendrá algo como Django, Rails o Zend.

Los marcos generalmente dan como resultado una mayor productividad (tal vez después de una ligera curva de aprendizaje), pero a menudo hay un compromiso involucrado. En algunos casos, por ejemplo, gana productividad del programador a costa de una disminución del rendimiento.

Considere los mapeadores relacionales de objetos (ORM). Son geniales porque se encargan de mucho del tedioso código de mapeo para usted. Incluso pueden crear tus objetos para ti. Sin embargo, al abstraer el SQL, es mucho más difícil razonar sobre el rendimiento y optimizar sus cuellos de botella.

Si está creando una aplicación que no tendrá muchos datos o consultas complejas, el rendimiento puede no ser un problema para usted. De hecho, el tiempo del programador es el cuello de botella para muchos proyectos, y los marcos, las bibliotecas y los lenguajes de alto nivel ayudan a aliviar eso.

Estoy de acuerdo en que "Usas bibliotecas, pero los frameworks te usan a ti". Esa es una forma muy clara de decirlo. No estoy de acuerdo con que tan pronto como comience a reutilizar el código comience a construir un marco, ya que generalmente no necesita hacer mucho más que copiar y pegar rápidamente para volver a usar su código, eso es un biblioteca que está construyendo; no es necesario que te extrañes de cómo traes el código a tu sitio o aplicación.

Para mí, el punto crucial es que tengo que obtener más de un recurso de lo que requiere que invierta. O, desde otro ángulo, diría que tan pronto como las necesidades de un marco sean mayores que la (s) recompensa (s) disponible (s), toda ventaja está ausente. Entonces es '¡Sí! ¡Por favor! ¡Y gracias!' a todos los que hacen activos que caerán directamente y funcionarán según sea necesario dentro de mi propio html / CSS / PHP y SQL.

Una cosa que encuentro incomprensible es que se dice que los marcos facilitan el mantenimiento. Si la compleja malla de partes de interfuncionamiento no funciona como se esperaba, será mejor que sepa todo lo que hay que saber sobre el marco en cuestión. O prepárese para una gran entrada de nueva sintaxis.

Algunas personas dicen que este es el Principio de Hollywood de los marcos: "No nos llames, te llamaremos". Por el contrario, cada vez que usa una biblioteca, su código llama a la biblioteca , no al revés.

Como puede ver, el punto importante es quién tiene el control, es decir, el control del flujo de control. ¿Quién decide qué declaración se ejecuta después de cuál?

Hay argumentos a favor y en contra, y cada vez que veo discusiones tan interminables, tiendo a pensar que esto debe ser una cuestión de gustos, más que una pregunta objetivamente decidible. De lo contrario, ya se habría decidido.

Desde mi punto de vista, si prefiere usar frameworks o bibliotecas dice algo sobre qué tipo de desarrollador es usted, y no si uno de los dos enfoques es superior y eventualmente prevalecerá.

Si prefiere los marcos, prefiere intercambiar libertad por seguridad: probablemente sea más pragmático y tiende a confiar en que otros harán su trabajo correctamente. Si prefiere las bibliotecas, prefiere cambiar la seguridad por la libertad: probablemente sea más idealista y cuestione las ideas y afirmaciones de los demás.

No creo que sea prudente decidir que es mejor ser como el primero o el segundo.

Respondiendo a su pregunta: ¿Los marcos ponen demasiada abstracción? Depende de quién eres y, específicamente, con qué distancia de los primeros principios te sientes cómodo.

...

Y aún más específicamente, si no te gustan los frameworks como Django, busca "microframeworks" como Flask :)