El dilema de los marcos

Como desarrollador, los frameworks suelen ser lo primero que se elige cuando se quiere acelerar las cosas y mantener la fiabilidad. La gente suele hablar de los frameworks como si fueran la solución perfecta que puede solucionar todos los problemas, haciendo que el desarrollo sea más rápido, más fácil y más eficiente. Sin embargo, si tienes algo de experiencia, sabes que los frameworks no son una solución única para todos. Elegir el correcto puede agilizar el trabajo, pero la elección incorrecta puede provocar dolores de cabeza en el futuro, ralentizándolo justo cuando necesita avanzar con rapidez.

En esta publicación del blog, analizaremos en profundidad los desafíos y las estrategias reales que conlleva la elección y el uso de marcos de trabajo. Analizaremos los posibles obstáculos, cómo evitarlos y las formas de mantener la flexibilidad de la base de código, incluso cuando se utiliza un marco de trabajo.

La relación en la que no sabías que te estabas metiendo

Comprometerse con un marco de trabajo es un poco como iniciar una relación a largo plazo, y no es algo que se pueda tomar a la ligera. A diferencia de una biblioteca sencilla o una pequeña utilidad, los marcos de trabajo vienen con opiniones, muchas de ellas. Imponen una estructura y una metodología a tu aplicación, te guste o no.

Es fundamental recordar que los creadores de frameworks tienen sus propias prioridades. Están resolviendo SUS problemas, no los tuyos. No te deben nada (a menos, por supuesto, que tengas un amigo en el equipo interno de frameworks, en cuyo caso, ¡qué suerte tienes!). Si las cosas van mal, especialmente en una etapa avanzada de tu proyecto, podrías tener un gran problema. Ahora estás obligado a solucionarlo o, peor aún, a eliminarlo por completo.

No es divertido, ¿verdad?

Por lo tanto, antes de comprometerse con un marco de trabajo, asegúrese de que realmente se ajuste a sus necesidades. De lo contrario, estará jugando a los dados.

Problemas de FAANG

El autor no tiene idea si FAANG se convirtió en MAANG, MANGA, o si ahora todos estamos en un anime.

Aquí es donde la experiencia realmente cuenta. Cuando las empresas crecen rápidamente, a menudo se enfrentan a desafíos que ninguna solución estándar puede manejar. La escala de estos problemas las obliga a crear sus propias herramientas (bases de datos personalizadas, motores ETL, herramientas de inteligencia empresarial, etc.). Los gigantes de la tecnología como Google, LinkedIn, Spotify y Netflix han liderado el camino, creando y publicando herramientas con las que el resto de nosotros ahora podemos jugar.

Pero lo importante es que estas herramientas no se diseñaron para que se aplicaran de manera universal, sino para resolver problemas específicos que la mayoría de las empresas nunca encontrarán. Los ingenieros que han trabajado en estas grandes empresas están acostumbrados a lidiar con este tipo de desafíos: han creado soluciones que funcionan a una escala que la mayoría de nosotros solo podemos imaginar. Por eso, cuando se trasladan a empresas más pequeñas, las decisiones que toman sobre el marco y las herramientas se basan en un profundo conocimiento tanto del poder como de los inconvenientes de estas tecnologías.

Resistencia a los marcos de referencia

Últimamente, se ha estado gestando una especie de rebelión: la gente se está cansando de los frameworks. Especialmente en el mundo de JavaScript, los desarrolladores están hartos de la renovación constante. Probablemente lo hayas visto: cada vez que se lanza una actualización importante, tienes que reescribir partes importantes de tu base de código solo para seguir siendo relevante. Y no me hagas hablar del ciclo interminable de cambios disruptivos.

Esta frustración ha dado lugar a un resurgimiento de stacks más simples y estables. Cosas como HTML, CSS, jQuery, PHP y SQLite están volviendo entre los desarrolladores que priorizan hacer las cosas por encima de mantenerse a la vanguardia de la tecnología. Sí, puede parecer un poco "de la vieja escuela", pero está lejos de ser obsoleto. Con un stack más simple, puedes iterar rápido y enviar aún más rápido. Claro, los frameworks más nuevos como React, Node.js y Flask tienen su lugar, pero a veces no necesitas todas las cosas sofisticadas. A veces, apegarse a lo que funciona puede ahorrarte muchos dolores de cabeza.

¿El complejo industrial marco?

¿Se están volviendo los frameworks... sobrevalorados? Es difícil no darse cuenta de que algunos frameworks parecen más herramientas diseñadas para atraer fondos de capital riesgo que para resolver problemas reales de los desarrolladores. Es como si hubiera todo un ecosistema que empuja a los desarrolladores hacia estos frameworks, solo para que se den cuenta más tarde de que, una vez que escalan, están atrapados en plataformas costosas. Claro, los frameworks como Databricks son de código abierto y gratuitos al principio, pero a medida que creces, te empujan hacia sus soluciones empresariales. Y de repente, tus costos de alojamiento y operativos se disparan, mientras que un simple VPS podría haber sido suficiente.

Parece un poco una trampa ¿no?

Retraso de la Decisión Marco

Este es un consejo que recomiendo encarecidamente: no se apresure a elegir un marco de trabajo . No se comprometa hasta que su arquitectura esté completamente definida.

El marco debería ser lo último de lo que preocuparse, no lo primero.

En primer lugar, asegúrese de que su arquitectura sea sólida. Conozca sus componentes principales y cómo interactuarán. Una vez que lo tenga claro, podrá evaluar los marcos de trabajo con una comprensión clara de dónde podrían encajar, o si es que encajan en absoluto.

Este enfoque garantiza que su diseño sea sólido y se adapte a sus necesidades específicas. Cuando llegue el momento de considerar un marco, podrá ver claramente dónde puede mejorar su arquitectura sin limitarla.

Antes de comenzar a usar un framework, pregúntese: ¿realmente lo necesita? Por supuesto, los frameworks pueden agregar capas de automatización y conveniencia, pero también tienen sus propias limitaciones. Si su aplicación tiene requisitos únicos, es posible que los frameworks no funcionen bien con ellos.

Piense detenidamente en los beneficios a largo plazo frente a las limitaciones.

Hacer que los marcos sean prescindibles

Si decide que vale la pena correr el riesgo de usar un marco, asegúrese de que sea fácil de reemplazar. Sí, escuchó bien. Incorpore cierta flexibilidad para que, si necesita deshacerse de él más adelante, no sea una tarea monumental. A continuación, le indicamos cómo:

Resume tus dependencias

Mantenga las sucias manitas del marco alejadas de su código principal. Utilice interfaces para abstraer la funcionalidad del marco de modo que su lógica empresarial no dependa directamente del marco.

Supongamos que utiliza TensorFlow para el aprendizaje automático. En lugar de incorporar código de TensorFlow en toda la aplicación, defina interfaces para mantener todo ordenado y abstracto:

 from abc import ABC, abstractmethod import tensorflow as tf class ModelTrainer(ABC): @abstractmethod def train(self, data): pass class TensorFlowTrainer(ModelTrainer): def train(self, data): # TensorFlow-specific training logic model = tf.keras.models.Sequential([...]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy') model.fit(data, epochs=5) return model

Al hacer esto, la lógica central no está estrechamente acoplada con TensorFlow. Si necesita cambiar a otro marco de aprendizaje automático, solo es cuestión de cambiar la implementación.

La inyección de dependencia (DI) es tu amiga

A continuación, hablemos de la inyección de dependencias (DI). Esta técnica le permite inyectar implementaciones específicas de sus interfaces en sus clases, manteniendo su base de código desacoplada y modular.

 class TrainingPipeline: def __init__(self, trainer: ModelTrainer): self.trainer = trainer def execute(self, data): return self.trainer.train(data) # Inject the TensorFlowTrainer implementation pipeline = TrainingPipeline(TensorFlowTrainer())

Ahora su código es flexible, fácil de probar y está listo para lo que el futuro le depare.

Adopte la inversión de control (IoC)

Para lograr la máxima flexibilidad, lleve las cosas a otro nivel con Inversión de control (IoC). Este patrón le permite especificar implementaciones en un archivo de configuración o en una ubicación centralizada en su código. Es la cereza del pastel de su arquitectura independiente del marco.

A continuación se muestra un ejemplo de cómo podría funcionar con un enfoque basado en la configuración:

 # config.py class Config: TRAINER = 'my_project.trainers.TensorFlowTrainer' # main.py import importlib class TrainingPipeline: def __init__(self, trainer_class: str): module_name, class_name = trainer_class.rsplit('.', 1) module = importlib.import_module(module_name) trainer_cls = getattr(module, class_name) self.trainer = trainer_cls() def execute(self, data): return self.trainer.train(data) # Inject the trainer specified in the configuration from config import Config pipeline = TrainingPipeline(Config.TRAINER)

Ahora, si alguna vez necesitas reemplazar TensorFlow con otro marco de aprendizaje automático, simplemente actualizas la configuración y continúas. Sin problemas ni dramas.

Conclusión

Recuerde que los marcos de trabajo deben servir a SU arquitectura, no dictarla. Con una planificación cuidadosa y una abstracción estratégica, puede aprovechar los beneficios de los marcos de trabajo sin quedar atrapado en dependencias a largo plazo. El truco es mantener el control. Así que la próxima vez que esté a punto de sumergirse en un marco de trabajo, dé un paso atrás y recuérdese: usted es quien manda.

¡Gracias por leer!

¿Tienes alguna pregunta? ¡Deja tu comentario a continuación para iniciar fantásticas discusiones!

Echa un vistazo a mi blog o ven a saludarme 👋 en Twitter o suscríbete a mi canal de Telegram . ¡Planifica lo mejor que puedas!