Cuándo NO usar un marco [cerrado]

Hoy en día, uno puede encontrar un marco para casi cualquier idioma, para adaptarse a casi cualquier proyecto. La mayoría de los marcos modernos son bastante robustos (en términos generales), con horas de prueba, código revisado por pares y gran extensibilidad.

Sin embargo, creo que hay un inconveniente en CUALQUIER marco en el que los programadores, como comunidad, pueden volverse tan dependientes de sus marcos elegidos que ya no entienden el funcionamiento subyacente, o en el caso de los programadores más nuevos, nunca aprendan el funcionamiento subyacente para empezar con. Es fácil especializarse hasta el punto de que ya no es un "programador PHP" (por ejemplo), sino un "programador Drupal", con exclusión de cualquier otra cosa.

A quién le importa, ¿verdad? Tenemos el marco! ¡No necesitamos saber cómo "hacerlo a mano"! ¿Correcto?

El resultado de esta pérdida de habilidades básicas (a veces en la medida en que los programadores que no usan marcos son vistos como "desactualizados") es que se convierte en una práctica común usar un marco donde no es necesario o apropiado. Las características que el marco facilita terminan confundiéndose con lo que el lenguaje base es capaz de hacer. Los desarrolladores comienzan a usar marcos para realizar incluso las tareas más básicas, de modo que lo que alguna vez se consideró un proceso rudimentario ahora involucra grandes bibliotecas con sus propias peculiaridades, errores y dependencias. Lo que una vez se logró en 20 líneas ahora se logra al incluir un marco de 20,000 líneas Y escribir 20 líneas para usar el marco.

Por el contrario, uno no quiere reinventar la rueda. Si escribo código para realizar alguna pequeña tarea básica y común, podría sentir que estoy perdiendo el tiempo cuando sé que el framework XYZ ofrece todas las funciones que busco, y mucho más. La parte de "mucho más" todavía me preocupa, pero parece que muchos ni siquiera lo consideran.

Tiene que haber una buena métrica para determinar cuándo es apropiado usar un marco. ¿Cuál considera que es el umbral? ¿Cómo decide cuándo usar un marco o cuándo no?

"Tiene que haber una buena métrica para determinar cuándo es apropiado usar un marco".

Realmente no. Si hubiera buenas métricas para determinar el uso apropiado de cualquier tecnología, no vería el lenguaje, el editor y la metodología de las guerras santas.

Todos los grupos con los que he trabajado hacen lo mismo: adivinan los costos y beneficios, eligen la ruta más productiva y esperan que tengan razón. No es terriblemente científico: una parte de intuición, tres partes de experiencia, una parte de susceptibilidad al marketing, una parte de astucia y cinco partes de opinión de rango.

Los marcos son solo herramientas. No creo que sea culpa de un marco si se usa en exceso, sino de la persona que lo usa en exceso. El viejo dicho "si tienes un martillo, todo parece un clavo" muestra que esta forma de pensar ha existido mucho antes incluso de las computadoras.

Volverse demasiado especializado puede convertirse en un problema a largo plazo, tanto para un desarrollador como para especies biológicas. Para la supervivencia a largo plazo, uno tiene que equilibrar cuidadosamente el esfuerzo para desarrollar sus habilidades en múltiples áreas.

Para responder a su pregunta específica, no creo que haya una métrica para esto. Prefiero usar un marco cuando simplifica la resolución de problemas. Si usar un marco me ayuda a resolver un problema con 2 líneas de código en lugar de 20, obviamente lo usaré. Pero incluso si son 20 líneas contra 20, podría decidir usar un marco si me da mejores abstracciones, más cerca del dominio del problema, haciendo que el código sea más fácil de entender y mantener.

Creo que los marcos pueden ser utilizados en exceso en algunos contextos, sí. Un marco es solo una herramienta, sí. Un marco le permite hacer que algo se ejecute muy rápidamente y, como tal, es una excelente herramienta de creación de prototipos.

En algún momento, cuando su aplicación alcanza cierto nivel de complejidad, las restricciones inherentes a un marco comienzan a sofocar un mayor crecimiento, me parece. El truco es reconocer cuándo se ha encontrado con un punto de inflexión y luego decidir qué va a hacer al respecto.

Tiendo a trabajar más con aplicaciones web y aunque trato de ser general, mi respuesta podría no aplicarse a su área de programación.

También voy a usar "marco" sinónimo de "biblioteca".

Antes de implementar un marco, uno debe considerar algunas cosas, aquí hay algunos ejemplos generales.

# 1 ¿El marco ahorrará tiempo y esfuerzo?

La respuesta a esta pregunta es casi siempre sí . Los marcos tienden a construirse para resolver problemas específicos y resolverlos muy bien. Por ejemplo, marcos como EntityFramework pueden salvarlo completamente de escribir código SQL. Lo que puede ser fantástico si su equipo de programación no domina SQL.

Los marcos se construyen para: a) agregar una interfaz amigable para el programador a componentes complejos o b) agregar abstracción a componentes ya conocidos (o establecidos).

El último (o incluso el primero en algunos casos) puede en realidad obstaculizar el desarrollo. Esto se aplica especialmente cuando usted o su equipo de programación va a implementar un nuevo marco, en el que nunca antes han trabajado.

Esto podría ralentizar su proceso de desarrollo, lo que podría ser costoso.

# 2 La escala de su aplicación

Se dice que "cualquier cosa que valga la pena hacer es exagerar" , pero generalmente ese no es el caso. Probablemente no haya una buena razón para implementar un marco de gran tamaño si el objetivo de su aplicación es imprimir "papa" .

Cuando está desarrollando una aplicación (ya sea web, de escritorio, móvil o cualquier otro tipo de aplicación concebible), si siente que el tamaño de su marco "eclipsa" su implementación (tal vez futura), entonces esta podría ser una gran señal de advertencia de que su marco podría simplemente hinchar su aplicación. Una buena anécdota sería si incluyera jQuery, solo para agregar una clase "cargada" a su etiqueta de cuerpo cuando el documento esté listo. Hacer eso solo con JavaScript nativo puede ser un poco más difícil , pero no hincha tu aplicación.

Por otro lado, si un marco hace mucho trabajo sucio en el interior (es decir, marcos de bases de datos), entonces podría ser viable implementarlo, incluso si solo está usando el marco "parcialmente". Una buena anécdota sería no intentar construir su propio controlador ADO.NET o MongoDB, simplemente porque no necesita utilizar toda la biblioteca.

A veces, los marcos vienen de código abierto (y con licencias de 'haz lo que quieras'). Esto abre una nueva posibilidad en la que un equipo de programación solo puede optar por partes de un marco.

Esto finalmente se vincula con las preguntas 1 y 3.

# 3 Impacto.

A veces, implementar un marco puede afectar directamente al usuario final. Esto es especialmente cierto para las aplicaciones web, ya que tener grandes marcos del lado del cliente podría afectar negativamente la experiencia del usuario final. Los usuarios con máquinas más lentas pueden experimentar renderizado lento, problemas de rendimiento con JavaScript o problemas similares causados ​​por máquinas de baja calidad. El usuario con conexiones lentas puede experimentar tiempos de carga lentos (al menos iniciales).

Incluso en otros tipos de aplicaciones, los usuarios finales pueden verse afectados negativamente por las dependencias de sus aplicaciones. Los marcos al menos siempre ocupan algo de espacio en el disco, y si está desarrollando una aplicación móvil (o incluso una aplicación de escritorio), esto podría ser necesario tener en cuenta.

Los marcos del lado del servidor (incluso más específicos de la web) probablemente no afectarán a sus usuarios finales, pero afectarán a su infraestructura . Algunos marcos tienen dependencias mismos que podrían requerir que reinicie el servidor web, ya sea sólo el servicio o el servidor completo.

Algunos marcos también pueden ser muy pesados ​​en recursos.

Por supuesto, esto se remonta a los puntos 1 y 2.

Todo es solo un gran "círculo de consideraciones", y no existe un método científico real para decidir si debe implementar un marco o no.

Corbin March lo resumió muy bien:

Todos los grupos con los que he trabajado hacen lo mismo: adivinan los costos y beneficios, eligen la ruta más productiva y esperan que tengan razón. No es terriblemente científico: una parte de intuición, tres partes de experiencia, una parte de susceptibilidad al marketing, una parte de astucia y cinco partes de opinión de rango.

También es importante no ser elitista . Los marcos son herramientas destinadas a ser utilizadas. Conozco personas de ambos extremos; por un lado, tienes al tipo que hace la vida muy difícil para sí mismo; por el otro lado, tienes al tipo que crea aplicaciones lentas e hinchadas.

Todos los marcos tienen casos de uso, solo es cuestión de implementarlos para los fines correctos.

¿Los otros desarrolladores conocen el marco?

Si todos los desarrolladores conocen el marco X, entonces todas las otras razones para usar el marco son viables, ¡adelante! Para mí, no tiene ningún sentido imponer el aprendizaje de un marco específico cuando la mayor parte del tiempo de desarrollo se dedicará a aprender las complejidades del marco.

Con respecto a su declaración sobre los nuevos programadores que no conocen los conceptos básicos, ¡usted es mucho más compasivo que yo! Sí, es una pena, pero ¿voy a pasar mi tiempo preocupándome por la ineptitud de otra persona? Nup. (Basado en el supuesto de que estos nuevos miembros de la comunidad no están trabajando inmediatamente con usted).

Usaría un marco si (y SOLO si) las siguientes condiciones son ciertas:

El marco parece ser compatible durante algún tiempo. Los he tenido al final de mi vida antes, y es REALMENTE molesto. Especialmente cuando tienes 9 meses en tu proyecto, y el cambio ya no es una opción. Y si el marco ya NO es compatible, piense tres veces antes de escribir algo nuevo usando ese marco. No importa cuán bien ya lo sepas.

El proyecto realmente coincide con el marco. Como un ejemplo bastante antiguo, ¿has visto las cosas para las que se hizo MFC? La gente no dejaba de hacer cosas extrañas para que funcionara para tipos de aplicaciones donde simplemente no tenía sentido. Por lo general, pasan más tiempo golpeando MFC de lo que hubieran gastado escribiendo la aplicación que querían directamente.

El equipo del proyecto es capaz de trabajar dentro del marco. Algunas personas no pueden o no pueden tomarse el tiempo para comprender cómo se debe escribir una aplicación en un marco determinado, y en su lugar escriben las cosas de la forma en que lo hacen habitualmente, en lugar de la forma en que el marco necesita. Este desajuste entre el código y el marco generalmente termina costando a todos mucho tiempo y esfuerzo.