Los Framework de desarrollo, un "regalo envenenado"

Voy a expresar algo que, aunque a muchos desarrolladores “horrorizará”, estoy seguro de que muchos otros comparten: Los Framework  (marcos de desarrollo) son un “regalo envenenado”.

Aunque su uso está muy extendido y existen muchos Frameworks, generalmente suelo evitar su uso para los proyectos en que participo y creo que en muchos casos, a pesar de sus aparentes ventajas, son contraproducentes.

Por supuesto esto no es una norma absoluta, y hay casos en que sí me parece apropiado, ya sea por normalizar desarrollos o porque el proyecto lo requiera.
El problema es que muchos Arquitectos y Desarrolladores dan por supuesto que “deben utilizarse”, que "es la mejor opción" y “te miran como un marciano” si, por ejemplo, argumentas que prefieres no usar Hibernate.

Sin embargo, tal como predica el pensamiento crítico, no debemos asumir nada sin reflexionar. Argumento a continuación por qué no es tan evidente la ventaja.

 

Framework vs bibliotecas.

El primer punto a aclarar es la denominación de Framework de desarrollo y su diferencia con las bibliotecas de desarrollo, librerías o APIs de productos o servicios.

En cualquier lenguaje de programación, cuando hablamos de bibliotecas, nos referimos a un conjunto de funciones , métodos y clases que nos permiten realizar diversas operaciones (ordenar listas de valores, reproducir archivos de audio o video, generar gráficos, acceder a servicios o a bases de datos,  etc.). Por tanto cuando desarrollamos un programa y utilizamos bibliotecas, debemos construir y elaborar la lógica del programa, y cuando necesitamos utilizar unos servicios “especializados”, en lugar de programarlos desde cero, se acude a esas bibliotecas que alguien ha construido previamente (y que se habrán publicado como software libre o  como producto privativo, con sus correspondientes licencias). Es decir en este escenario, la lógica y el marco de trabajo lo impone el proyecto, que solo acude a las bibliotecas para algunas funciones.

En cambio, cuando desarrollamos utilizando algún framework (como AngularJS, Struts,  SpringBoot  o Ruby on Rails ) el marco o modelo de trabajo lo fija el Framework, que impone una estructura, una lógica y una forma de trabajo, dentro de la cual la tarea de desarrollo del proyecto es “rellenar los huecos” (lo que no implica que sea poco trabajo, pueden ser "huecos" enormes de miles de horas de desarrollo por supuesto).

Modelo MVC usado en Frameworks como Struts (by Wooptoo [Public domain])

Comparando con un modelo más cercano a todos, si estuviéramos construyendo una estantería para nuestra casa, el modelo de desarrollo basado en librerías equivaldría a cortar las maderas a medida y, para las piezas complicadas, como cajones o elementos abatibles, comprar esas piezas ya hechas.

En cambio el equivalente a utilizar un Framework sería comprar unas estanterías con unas dimensiones fijas, y rellenar los huecos con baldas para adaptarse a nuestras necesidades.

Por supuesto el modelo no es totalmente exacto y además en ocasiones la frontera es difusa, ya que los Framework tiene bibliotecas de funciones adicionales/complementarias y las bibliotecas en ocasiones imponen una forma de trabajo. Pero como aproximación creo que es válida.

Con una biblioteca, el desarrollador “manda”, dirige el flujo y lógica e invoca las funciones deseadas cuando se necesitan-

Con un Framework, el desarrollador se “adapta” al Framework, se ajusta a esa lógica y “contrato" y es “invocado” dentro de ese modelo.

 

Ventajas de los Framework.

Por supuesto, los Framework tienen muchas ventajas:

• Conforman un esqueleto bien estructurado, con lo que no hay que pensar en muchos aspectos (gestión de errores, verificación datos, etc.), pues ya están previstos.
• Cuando hay un equipo grande, o varios equipos en una empresa, asegura que todos los proyectos se desarrollen igual.
• Las personas que se incorporen a la empresa, al ser un Framework estándar, es posible que conozcan ese Framework, y pueden ser productivos antes.

Telco [Public domain]

En muchas ocasiones, y como se da por supuesto que “los Framework son muy útiles y aumentan la productividad”, solo se recuerda las ventajas, o incluso no se analiza, simplemente se utilizan porque “ahora se programa así”.
Sin embargo, “no es oro todo lo que reluce”.

 

Inconvenientes de los Framework.

Entre los principales inconvenientes, puede citarse:

• El “sobrepeso”: Muchos Framework son “monstruosos”, e introducen una sobrecarga muy importante, lo que implica mucho más hardware para poder prestar los mismos servicios. El ahorro en tiempo de desarrollo puede no compensar el coste en infraestructura adicional.
• La compatibilidad: En ocasiones, los Framework cambian la forma de trabajo y te obligan a cambiar gran parte del código y/o de la lógica de un proyecto. Quizá un ejemplo “sangrante” es el cambio en alguna versión de AngularJS, que lo convertía en totalmente incompatible con la versión anterior. En cambio, si una biblioteca cambia ciertos métodos o clases, es posible realizar cambios en la llamada a esos métodos, o incluso crear un recubrimiento con el “contrato” anterior, que convierta internamente las llamadas al nuevo estilo, sin afectar demasiado al grueso del programa.
• El exceso de dependencias: Es habitual que muchos Framework arrastren muchas herramientas y bibliotecas. ¿Qué ocurre si además del Framework queremos usar otras bibliotecas, como es habitual? Esas bibliotecas, que en ocasiones requieren bibliotecas adicionales complicando aún más el escenario, pueden colisionar con las del propio Framework. El resultado es que no puedes utilizar la biblioteca que deseas y hay que buscar otras. Hay otro efecto peor, que es que la incompatibilidad surja a posteriori, es decir cuando se actualiza la versión del Framework y descubres que colisiona con alguno de los elementos que ya utilizas, lo que obliga a hacer (bastantes) cambios. Por supuesto, pueden surgir colisiones entre bibliotecas aunque no se utilice Framework, pero las probabilidades son menores y, además, siempre pueden cambiarse por otras con menos impacto que el rehacer toda la lógica.
• La continuidad en el tiempo: Si una biblioteca desaparece, se cambia por otra con relativo esfuerzo. Si un Framework desaparece, hay que “rehacer” el proyecto.
• El aprendizaje: Los Framework suelen ser grandes y complejos, lleva tiempo aprenderlos y entender la lógica y empezar a desarrollar bajo ellos.
• La evolución: Al ser muy grandes, la evolución puede ser lenta y no estar disponibles para, por ejemplo, la última versión de Java, base de datos, navegador o sistema operativo.

 

¿Hay alternativas?

Si se desea acelerar el desarrollo, aumentar la calidad (evitando errores) y seguir una estructura común (para facilitar la movilidad entre equipos). ¿No hay más remedio que utilizar Framework?

No necesariamente, hay diversos recursos:

• Crear un mini-Framework propio, creando una estructura de clases que gestionen el esqueleto, incluyendo todos los controles de errores y escenarios necesarios, y dejando que los proyectos creen subclases y sobrecarguen los elementos necesarios. No serán tan sofisticados como un framework, pero a cambio:
• Estarán más adaptados a nuestros desarrollos y negocio
• Serán mucho más ligeros
• No se depende de terceros y por tanto pueden evolucionarse como nuestros desarrollos requieran.
• Crear patrones internos, de forma que los desarrollos tengan un modelo o proyecto tipo, que se copie y cambie.
• Definir normativas y recomendaciones internas.
•  . . . .

 

Conclusiones

Creo que si se desea un nuevo proyecto (o reorganizar un equipo de desarrollo), antes de asumir que se utilizará el Framework XYZ (o al contrario, asumir que NO se utilizará NINGÚN Framework) es imprescindible plantearse preguntas como:

¿Cuánto ahorro en tiempo de desarrollo frente a cuánto tardo en aprenderlo?
¿Aprovecho el 100% del Framework o solo un pequeño porcentaje?
¿Es más eficaz utilizar uno o construir uno mismo un pequeño framework o librerías?
¿Es estable o puede cambiar?
¿Qué sobrecarga introduce en términos de recursos de máquina requeridos?
¿Es válido para muchos proyecto o solo este?
¿Arrastrar muchas librerías? ¿Cuales?
¿Qué limitaciones de ejecución y plataforma me impone?
. . .

Una vez sopesadas todas las opciones, con una visión crítica podremos elegir la más adecuada que en ocasiones podrá ser la que inicialmente esperábamos como “normal” y en otros casos no, pero en cualquier caso habrá sido una decisión sopesada y SIN ASUMIR nada.