¿La abundancia de frameworks está abrumando a los programadores? [cerrado]

Con todos los marcos disponibles en estos días, ORM , inyección de dependencia (DI), Inversión de control (IoC), etc., encuentro que muchos programadores están perdiendo o no tienen las habilidades de resolución de problemas necesarias para resolver problemas difíciles. Muchas veces, he visto comportamientos inesperados en las aplicaciones y los desarrolladores no pueden realmente investigar y encontrar los problemas. Me parece que se está perdiendo una comprensión profunda de lo que sucede debajo del capó.

No me malinterpreten , no estoy sugiriendo que estos marcos no sean buenos y no hayan hecho avanzar a la industria, solo preguntando si, como consecuencia involuntaria, los desarrolladores no están obteniendo el conocimiento y la habilidad necesarios para una comprensión profunda de sistemas.

Convenido. Actualmente trabajo en un paquete de software que está tan afectado por los marcos que hace que sea casi imposible entender el negocio. Una vez que los marcos lo eliminan de la resolución de problemas comerciales en lugar de solo resolver MVC , ha ido demasiado lejos. Como usted dice, muchos programadores de IMO intentan crear un arquitecto / programa para resolver el ORM y el MVC, y rara vez preguntan si eso realmente ayuda de alguna manera a resolver el problema para el que el software está allí en primer lugar.

Sí, sé que ver un SQL en bruto en una página JSP es un "no-no", pero si eres un consultor de campo, ¿dónde encaja esto en una solución específica? Y no, eso no significa que el marco no sea correcto, no todos los clientes tienen $ 20k sentados a cada paso para garantizar que se proyecte un punto de datos menor en la página.

Este es un argumento que aparece regularmente, en muchos campos y en muchas formas.

La forma general de este argumento es:

¿Tener [x: herramienta / tecnología] empeora a las personas en [y: función afectada por x]?

Por ejemplo:

• ¿El software CAD es peor para los ingenieros?
• ¿Las calculadoras en la escuela secundaria empeoran a los estudiantes en matemáticas?
• ¿El software social atrofia las habilidades sociales en persona de las personas?
• ¿El software de contabilidad produce contadores peores?

De memoria, la respuesta omnipresente es casi siempre: no realmente. Siempre tendrás personas que son buenas y malas para hacer [y] pero ahora son malas en una faceta diferente de la habilidad.

Ayudará una comprensión más profunda de los fundamentos de cualquier trabajo, sin importar lo que haga, incluso los trabajos que se consideran 'correctivos'. El conocimiento siempre ayuda.

La abstracción es un concepto clave de la programación de computadoras y los marcos ayudan a los programadores a lograr esto. Ésto es una cosa buena. ¡Dudo que a muchos nos gustaría desarrollar sistemas complejos en lenguaje ensamblador! El problema surge, creo, cuando los programadores tienen poca idea de lo que está ocultando la capa de abstracción. En otras palabras, debe tener una idea de lo que sucede debajo del capó, incluso si no interactúa o interactúa directamente con él.

Recuerdo haber desarrollado algunos de los primeros sitios web dinámicos a mediados de los 90, utilizando C y CGI (en un momento en que la mayoría de los sitios web todavía eran HTML estático). Realmente no había ningún lenguaje de script maduro del lado del servidor (como PHP o ASP) y muy pocas bibliotecas, por lo que tenía que escribir todo el flujo de respuesta HTTP al servidor con cada página. Para analizar los parámetros GET y POST es necesario escribir su propia biblioteca. Fue tedioso, lento, arduo y muy propenso a errores. ¡No me lo pierdo ni un poco!

Sin embargo, también siento que los marcos como los formularios web ASP.NET abstraen toda la naturaleza sin estado de la web hasta el punto en que muchos desarrolladores web nuevos tienen poca idea de lo que realmente está sucediendo bajo el capó. Esto conduce a un código ineficiente e inflado que funciona mal porque el desarrollador está conectando componentes usando una metodología de "arrastrar y soltar" sin darse cuenta de lo que está sucediendo a nivel HTTP.

Por lo tanto, creo que los marcos son esenciales para desarrollar software de alto nivel, pero no eximen a los desarrolladores de tener una cierta comprensión de lo que se está abstrayendo. Sí, los marcos pueden hacerte tonto, pero solo si no los entiendes.

¿La transmisión automática o los limpiaparabrisas con sensor de lluvia nos hacen peores conductores?

No creo que la codificación sin marcos necesariamente implique una mejor comprensión de los sistemas subyacentes. Esto se evidencia por los empleadores que tienen que hacer preguntas simples de codificación en las entrevistas solo para asegurarse de que el candidato pueda unir un método coherente.

En última instancia, depende del desarrollador aprender. Los buenos sí, los malos no.

Y en una línea similar, elegir un marco solo porque está allí sin analizar realmente sus capacidades y pros / contras también es una señal de malas prácticas de desarrollo.

Creo que el problema es que los nuevos programadores están comenzando a niveles cada vez más altos de abstracción y, por lo tanto, no se exponen a los bits y bytes de las cosas 'bajo el capó'. Por lo tanto, no están aprendiendo algunos de los fundamentos de codificación realmente básicos que serían las primeras cosas aprendidas en años pasados.

Sacudo la cabeza cada vez que un programador obviamente nuevo pregunta algo sobre, digamos, almacenar algunos datos, y todos inmediatamente les dicen que usen una herramienta ORM . No, no, no, no, no ... primero necesitan aprender cómo hacerlo ellos mismos.

¿Quizás la distribución de "tontería" realmente no ha cambiado, y simplemente estamos entregando formas más grandes y complicadas para que los desarrolladores se disparen en el pie?

No son los marcos los que debilitan a los programadores. Los programadores tontos serán tontos si usan frameworks o no.

Ciertamente es cierto que comprender el trabajo de bajo nivel que una herramienta o marco le ayuda a optimizar lo convierte en un mejor usuario de las herramientas y marcos. También puede depurar problemas más fácilmente y solucionar los vacíos inevitables en la funcionalidad de las herramientas.

Por ejemplo, tomé una clase de diseño de compiladores en la universidad, donde codificamos un analizador LR desde cero en C, antes de aprender a usar generadores de analizadores como lex y yacc. Fue muy educativo, y desde entonces he tenido una mejor comprensión y apreciación de todos los lenguajes de programación que utilicé.

Pero no estoy diciendo que se requiera que cada programador trabaje con cera el auto del Sr. Miyagi durante años y años antes de que se les permita trabajar a un alto nivel. Gran parte del trabajo de programación es intelectual, y decide lo que el software debe hacer , no el trabajo mecánico de codificación en un lenguaje o herramienta en particular.

Ese trabajo intelectual es donde la inteligencia versus la tontería es aún más importante.

Citando el excelente "Spending Moore's Dividend" de James Larus (énfasis agregado):

Hace treinta años, Bill Gates cambió la solicitud en Altair Basic de "LISTO" a "OK" para guardar 5 bytes de memoria. Hoy en día, es inconcebible que los desarrolladores conozcan este nivel de detalle de su programa, y ​​mucho menos se preocupen por ello, y con razón, ya que un cambio de esta magnitud es hoy imperceptible ... No hay forma de que podamos producir los sistemas actuales. utilizando las prácticas artesanales y artesanales que eran posibles (necesarias) en máquinas con 4K de memoria.

Creo que probablemente sea engañoso decir que los marcos te permiten evitar las habilidades necesarias para resolver problemas difíciles o te permiten evitar una comprensión profunda. En cambio, la única razón por la que podemos construir los sistemas complejos de hoy (cuya complejidad puede generar problemas difíciles y desafiar la comprensión profunda) es porque tenemos marcos (y lenguajes recolectados de basura de alto nivel, e IDE con ayuda sensible al contexto y verificación de sintaxis sobre la marcha, y todos los otros avances en el desarrollo de software que a veces se critican como tontos programadores).

Los marcos son geniales. Pero tienes que saber qué hay debajo del capó. Entonces, el problema es que los programadores confían demasiado en los marcos, sin tener suficiente conocimiento del sistema subyacente.

Un ejemplo un tanto desactualizado es MFC : un programador podría ahorrar mucho tiempo usando MFC en lugar de la API de Windows, pero sin el conocimiento de la API (lo que significa tener antecedentes de trabajo real con la API sin procesar), a menudo se quedarían estancados. . Casi nunca sucedió, porque un programador típico de MFC tenía conocimiento de la API de Windows.

Sin embargo, con Windows Forms en .NET , gracias a la mejor encapsulación y al mejor modelo de objetos, un programador casi puede ignorar que está usando solo otro contenedor API de Windows. Por lo tanto, hay menos posibilidades de quedar atrapado, pero cuando sucede, puede doler.

Desafortunadamente, el tiempo de comercialización siempre es más corto y los proyectos son cada vez más complejos, por lo que los programadores no tienen tiempo para profundizar. Ese es el triste estado de la industria del software ...

Pone la inteligencia donde necesita estar. No es necesario comprender la mecánica cuántica y la física newtoniana para establecer un mecanismo que deje caer una pelota desde la parte superior de un edificio. Cada nueva capa en el software debe basarse en la última y eliminar la repetitiva de la construcción de aplicaciones útiles.

Aquellos que necesiten o quieran saber las "cosas" detrás del marco estudiarán e investigarán por las buenas o por las malas.

No absolutamente no. Los marcos son, en esencia, una combinación de una biblioteca de subrutinas y una plantilla, dos herramientas de programación probadas y verdaderas. Es un pobre trabajador el que culpa a sus herramientas ...

... y hay muchos trabajadores pobres que usan y culpan a los marcos.

Al crear software, los marcos ahorran tiempo. Al aprender a construir software, los marcos se interponen en el camino de la comprensión.

Creo que el problema es principalmente uno de las computadoras que se han vuelto demasiado poderosas. Para la mayoría de los programadores ya no hay una razón sensata para "ir a lo básico". Solo lleva más tiempo hacer lo mismo, y en el tiempo de ejecución no hay una diferencia significativa. La única forma de resolver eso es introducir restricciones artificiales, como lo hacen las competiciones como js1k.

¿Quizás las escuelas deberían tener una asignatura dedicada al "diseño optimizado" en la que hay que construir programas bajo fuertes restricciones de espacio y tiempo?

No, aprender los marcos mejora las habilidades de un programador. Framework es la extensión de un lenguaje de programación. Algunos idiomas ya están basados ​​en marcos. Trabajo con PHP y Java. PHP necesita un marco como el motor de plantillas (a veces). Java no necesita un marco (la mayoría de las veces), ya tiene muchos métodos y bibliotecas.

La mayoría de los Frameworks tendrán funciones que los programadores usarán una y otra vez.

Para jugar al parecer el abogado del diablo aquí, creo que los marcos ( "buenos", de todos modos) en realidad puede recorrer un largo camino hacia la promoción de la educación de un programador. Un marco bien diseñado resolverá muchos problemas, y al usar el marco, el programador puede llegar a comprender qué problemas se están resolviendo y cómo. En mi opinión, un marco es (/ debería ser) una cristalización de las mejores prácticas de programación, y puede enseñar a un programador por ejemplo.