Usar frameworks o no
Desarrollo guiado vs flexibilidad
Una de las preguntas más frecuentes a las que se enfrenta un equipo de desarrollo cuando comienza con un producto o proyecto nuevo es con que arquitectura y tecnologías lo construye. Y es que es una pregunta cuya respuesta puede marcar el éxito o el fracaso en el medio y largo plazo de un proyecto. Saber que cosas tener en cuenta y tomar la decisión de una manera informada es esencial.
Qué opciones tenemos 📦
A la hora de construir un nuevo servicio o aplicación tenemos diferentes opciones a nuestro alcance:
- Usar un framework: nos proporciona una estructura integral y opinionada y aplica una arquitectura y un flujo de trabajo específicos. Los desarrolladores trabajamos dentro de las limitaciones del framework y adaptándonos a su manera de hacer las cosas. Algunos ejemplos son Spring, Angular, Ruby on Rails, Django o .NET.
- Usar un conjunto de bibliotecas: una colección de funciones o módulos de código reutilizables que se pueden integrar según sea necesario, sin dictar la estructura general de la aplicación. Sería por ejemplo montar una API usando una biblioteca para crear servidores web como Express.js, Flask o Sinatra y usando otra para tener una capa de persistencia en base de datos como Prisma, SQLAlchemy o ActiveRecord (usado fuera de Rails). Pero montando nosotros mismos la estructura e integración entre las diferentes capas.
Como me gusta recordar a menudo, todas estas opciones son herramientas que tenemos a nuestra disposición y hay que saber cuándo usarlas. Todas tienen ventajas y desventajas y hay que tenerlas en cuenta para tomar la mejor decisión.
Haciendo referencia al libro de Software Architecture in Practice, en una sección que comenta sobre qué puede considerarse “buena” arquitectura nos desvela que las arquitecturas de software son evaluables, pero esa evaluación solo tiene sentido en el contexto específico que lo rodea.
Eso nos indica claramente que el objetivo de nuestro desarrollo y las condiciones en las que lo realizamos deben marcar la arquitectura y las herramientas que utilicemos para llevarlo a cabo.
Qué hemos de tener en cuenta 🔎
Por lo tanto, entender el contexto que rodea a nuestro producto es esencial para tomar la decisión.
Entre las cosas que pueden influir en si elegir un framework o un conjunto de bibliotecas específico están:
- El tiempo del que disponemos: a veces delimitado por las horas que tenemos disponibles para el desarrollo o por el time-to-market. Es el tiempo efectivo que tenemos para que el nuevo software acabe en producción.
- El equipo que tenemos: las personas que llevarán a cabo el desarrollo. Su background, su seniority y sus experiencias previas.
- El propósito de nuestro software: que necesidades está cubriendo nuestro software, su naturaleza (puede ser más o menos técnica) y si es un one-off o es un producto que va a seguir creciendo.
El tiempo del que disponemos ⏰
El desarrollo de software viene acotado muchas veces por el tiempo que tenemos para dedicarle. Tanto incluso que gran mayoría de la industria (al menos de la mitad que se dedica a consultoría) cobra directamente por las horas invertidas.
Y es un aspecto importante para tener en cuenta cuando elegimos con que tecnología desarrollar un sistema. ¿Con qué se tarda menos, con frameworks o con bibliotecas?
Pues depende.
Depende de qué estemos desarrollando, de la experiencia que tenga el equipo con las diferentes herramientas (más de esto abajo) y del trabajo adelantado que tengas como empresa (en forma de cosas que ya tengas hechas y puedas reaprovechar).
Como regla general y para productos sencillos (estilo CRUD o MVP temprano) suele asumirse que el uso de frameworks conlleva desarrollos más rápidos. Sin embargo, a medio plazo puede resultar limitante ya que estamos acoplados a una manera de hacer las cosas y puede que se nos ponga por delante a la hora de iterar el producto.
El equipo que tenemos 👥
Otro punto importante (y que también se relaciona con el tiempo que invertimos) es considerar el equipo del que disponemos.
En cuanto a su experiencia previa: si el día a día de tu equipo es desarrollar con un framework posiblemente tenga más sentido hacerlo con el mismo framework. En este caso invertir estratégicamente en formación en otras tecnologías puede ampliarte el abanico de opciones que tienes a la hora de tomar este tipo de decisiones.
En cuanto a su seniority: normalmente los frameworks ofrecen un desarrollo más guiado que beneficia a perfiles más juniors ofreciendo más estabilidad y maneras de hacer las cosas. Mientras que el uso de bibliotecas beneficia a perfiles más senior que son capaces de adaptar la aplicación con la mejor estructura posible para resolver el problema que se plantea.
Y esto afecta también directamente a la calidad de nuestro software, los frameworks pueden ayudar a compensar la falta de conocimientos o experiencia especializados dentro del equipo al proporcionar soluciones bien probadas y documentadas para desafíos de desarrollo comunes, cosa que beneficia a un equipo más junior. Sin embargo, muchas veces intentar forzar el adaptar un framework a un problema concreto puede desembocar en software de menor calidad.
El propósito de nuestro software 🚀
El objetivo de nuestro software también es importante a considerar cuando elegimos las herramientas con las que desarrollaremos.
No es lo mismo desarrollar un producto estático que no va a cambiar a corto ni medio plazo que construir un software que no va a parar de iterar.
Por otro lado, la naturaleza técnica del propio producto también es decisiva. Crear un ecommerce simple para vender productos de una tienda local es muy diferente a construir un SaaS para gestionar correos de clientes. Dependiendo de la complejidad técnica del producto y de lo resuelto que esté ya el problema en la comunidad puede tener más sentido una cosa o la otra.
Por lo tanto, si vamos a construir un software que va a estar en continua iteración o que tiene un componente de complejidad técnica elevado, es más recomendable el uso de bibliotecas ya que acoplarse a un framework puede traer problemas a medio plazo.
Al contrario, si vamos a construir un producto sencillo que ya ha sido resuelto por otros muchas veces o que no va a requerir mucho cambio podemos decantarnos por usar un framework.
Un punto intermedio 🤝
El uso de bibliotecas es la recomendación por la que me decanto en la mayoría de las situaciones. Aunque en casos donde tenemos un equipo bastante junior o donde nuestro producto es simple y no va a cambiar (o es de usar y tirar) un framework puede tener sentido.
Sin embargo, hay un punto intermedio que me gusta recomendar para estos casos que es el uso de boilerplates. Son un conjunto de archivos y código fuente que sirven como punto de partida o plantilla para un nuevo proyecto de software. Es una estructura básica y predefinida que proporciona la configuración inicial y algunas funcionalidades comunes necesarias para empezar a desarrollar una aplicación.
Construirnos un boilerplate con las bibliotecas que usamos habitualmente y una estructura recomendada puede suplir los beneficios que nos dan los frameworks con las ventajas y libertades que nos aportan las bibliotecas.
TL;DR
La elección entre el uso de frameworks o un conjunto de bibliotecas es una decisión crucial que debe tomarse considerando diversos factores. Es esencial comprender el contexto en el que se encuentra el proyecto, incluyendo el tiempo disponible, el equipo de desarrollo y el propósito del software. Si bien los frameworks pueden ofrecer una estructura integral y acelerar el proceso de desarrollo, también pueden limitar la flexibilidad a largo plazo. Por otro lado, las bibliotecas permiten una mayor adaptabilidad y control, pero pueden requerir más experiencia y esfuerzo para integrarlas correctamente.
En la mayoría de los casos, el uso de bibliotecas junto con la creación de un boilerplate personalizado puede ofrecer un equilibrio óptimo entre eficiencia y flexibilidad, proporcionando una base sólida para el desarrollo de software escalable y de calidad. En última instancia, la elección entre frameworks y bibliotecas depende de las necesidades específicas del proyecto y del equipo de desarrollo, y debe evaluarse cuidadosamente para garantizar el éxito a largo plazo del producto.