Como desenvolvedor, os frameworks adoitan ser o primeiro que colles cando queres acelerar as cousas e manter as cousas fiables. A xente adoita falar de marcos como se fosen a solución perfecta que pode solucionar todos os teus problemas, facendo que o desenvolvemento sexa máis rápido, sinxelo e eficiente. Non obstante, se tes algunha experiencia no teu cinto, sabes que os cadros non son unha solución única. Escoller o correcto pode axilizar o teu traballo, pero a elección incorrecta pode provocar dores de cabeza ao longo do camiño, que o retardan xusto cando necesitas moverte rapidamente.  Nesta entrada do blog, mergullaremos nos retos e estratexias reais que se presentan coa elección e uso de marcos. Analizaremos as posibles trampas, como evitalas e formas de manter a súa base de código flexible, aínda que estea en xogo un marco.  A relación na que non sabías que estabas entrando  Comprometerse cun marco é un pouco como entrar nunha relación a longo prazo. E non é algo para tomar á lixeira. A diferenza dunha simple biblioteca ou dunha pequena utilidade, os frameworks veñen con opinións, moitas delas. Impoñen estrutura e metodoloxía á túa aplicación, queiras ou non.   É fundamental lembrar que os creadores de marcos teñen as súas propias prioridades. Están resolvendo os SEUS problemas, non os teus. Non che deben nada (a non ser que, por suposto, teñas un amigo no equipo do marco interno, nese caso, tes sorte). Se as cousas van cara ao sur, especialmente no fondo do teu proxecto, poderías sufrir un mundo ferido. Agora estás atrapado en arranxalo, ou peor aínda, arrincándoo por completo.  Non é divertido, non?  Entón, antes de vincularte a un marco, asegúrate de que realmente se adapta ao que necesitas. En caso contrario, estás tirando os dados.  Problemas FAANG  O autor non ten idea de se FAANG converteuse en MAANG, MANGA ou se agora estamos todos nun anime.  Aquí é onde a experiencia realmente conta. Cando as empresas crecen rapidamente, moitas veces enfróntanse a desafíos que ningunha solución estándar pode xestionar. A escala destes problemas obrígaos a crear as súas propias ferramentas (bases de datos personalizadas, motores ETL, ferramentas de BI). Xigantes das grandes tecnoloxías como Google, LinkedIn, Spotify e Netflix lideraron o camiño, construíndo ferramentas de código aberto coas que agora podemos xogar o resto.  Pero aquí está a cousa: estas ferramentas non foron creadas para ser de aplicación universal. Foron creados para resolver problemas específicos que a maioría das empresas nunca atoparán. Os enxeñeiros que traballaron nestas grandes empresas están afeitos a afrontar este tipo de desafíos: crearon solucións que funcionan a unha escala que a maioría de nós só podemos imaxinar. Polo tanto, cando se trasladan a empresas máis pequenas, as decisións sobre o marco e as ferramentas que toman baséanse nunha profunda comprensión tanto do poder como das trampas destas tecnoloxías.  Pushback Against Frameworks  Ultimamente, produciuse un pouco de rebelión: a xente está cansando de marcos. Especialmente no mundo de JavaScript, os desenvolvedores están fartos da constante rotación. Probablemente xa o viches: cada vez que se produce unha actualización importante, tes que reescribir partes importantes da túa base de código só para manterte relevante. E non me fagas comezar no ciclo interminable de cambios rotos.  Esta frustración deu lugar a un renacemento de pilas máis sinxelas e estables. Cousas como HTML de vainilla, CSS, jQuery, PHP e SQLite están volvendo entre os desenvolvedores que priorizan facer as cousas en lugar de manterse no vangarda da tecnoloxía. Si, pode parecer un pouco "vella escola", pero está lonxe de ser obsoleto. Cunha pila máis sinxela, pode iterar e enviar aínda máis rápido. Por suposto, os marcos máis novos como React, Node.js e Flask teñen o seu lugar, pero ás veces non necesitas todas as cousas extravagantes. Ás veces, seguir o que funciona pode aforrarche moitos dores de cabeza.  O complexo industrial marco?  Os frameworks están a ser... exagerados? É difícil non notar que algúns marcos parecen máis ferramentas deseñadas para atraer financiamento de VC que para resolver problemas reais dos desenvolvedores. É como se houbese todo un ecosistema que empurra aos desenvolvedores a estes marcos, só para que despois se dean conta de que, unha vez que escalan, están encerrados en plataformas caras. Por suposto, marcos como Databricks son de código aberto e gratuítos para comezar, pero a medida que creces, indúcese cara ás súas solucións empresariais. E, de súpeto, os teus custos operativos e de hospedaxe están polo teito, mentres que un simple VPS podería ser suficiente.  Parece un pouco unha trampa, non?  Atraso da Decisión Marco  Aquí tes un consello polo que xuro:   . Non te comprometas ata que a túa arquitectura estea completamente completa. non te apresures a escoller un marco  O marco debe ser o último que te preocupes, non o primeiro.  Primeiro, asegúrate de que a túa arquitectura sexa sólida. Coñece os teus compoñentes principais e como interactúan. Unha vez que teñas isto, podes avaliar os cadros cunha comprensión clara de onde poden encaixar, ou incluso se caben.  Este enfoque garante que o seu deseño sexa sólido e se adapte ás súas necesidades específicas. Cando chegue o momento de considerar un marco, poderás ver claramente onde pode mellorar a túa arquitectura sen limitala.  Antes de comezar a usar calquera framework, pregúntase:   Por suposto, os marcos poden engadir capas de automatización e comodidade, pero tamén teñen o seu propio conxunto de limitacións. Se a túa aplicación ten requisitos únicos, é posible que os frameworks non funcionen ben con eles. realmente o necesitas?  Pense moito e moito sobre os beneficios a longo prazo fronte ás limitacións.  Facendo os marcos prescindibles  Se decides que un marco paga a pena arriscar, asegúrate de que sexa fácil de substituír. Si, escoitaches ben. Inclúe certa flexibilidade para que, se necesitas abandonalo máis tarde, non sexa unha tarefa monumental. Aquí tes como:  Resume as túas dependencias  Mantén as pequenas mans sucias do framework fóra do teu código principal. Use interfaces para abstraer a funcionalidade do cadro para que a súa lóxica empresarial non dependa directamente do cadro.  Digamos que estás a usar TensorFlow para a aprendizaxe automática. En lugar de incrustar código TensorFlow en toda a túa aplicación, define interfaces para manter as cousas ordenadas e abstractas:   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  Ao facelo, a túa lóxica principal non está estreitamente unida a TensorFlow. Se precisa cambiar a outro marco de aprendizaxe automática, só é cuestión de cambiar a implementación.  A inxección de dependencia (DI) é o teu amigo  A continuación, imos falar da inxección de dependencia (DI). Esta técnica permíteche inxectar implementacións específicas das túas interfaces nas túas clases, mantendo o teu código base desacoplado e 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())  Agora o teu código é flexible, fácil de probar e listo para todo o que lle depara o futuro.  Abrace a inversión de control (IoC)  Para o máximo de flexibilidade, leva as cousas a un nivel superior con Inversión de control (IoC). Este patrón permítelle especificar implementacións nun ficheiro de configuración ou nunha localización centralizada no seu código. É a cereixa por riba da túa arquitectura agnóstica de marcos.  Aquí tes un exemplo de como isto pode funcionar cun enfoque baseado na 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)  Agora, se algunha vez necesitas substituír TensorFlow por outro marco de aprendizaxe automática, simplemente actualiza a configuración e continúa. Sen problemas, sen drama.  Conclusión  Lembre, os frameworks deben servir á SÚA arquitectura, non ditala. Cunha planificación coidadosa e unha abstracción estratéxica, podes aproveitar os beneficios dos frameworks sen quedar atrapado en dependencias a longo prazo. O truco é manter o control. Entón, a próxima vez que estea a piques de mergullarse nun marco, dá un paso atrás e recórdase: aquí decides ti.    Grazas por ler!  Algunha pregunta? Deixa o teu comentario a continuación para comezar fantásticas discusións!  Consulta   ou ven a saludar 👋 en   ou subscríbete á   . Planifica o mellor posible! o meu blog Twitter miña canle de Telegram

Subscribe

Buy My Book

Este audio está producido na lingua orixinal da historia!

O Dilema dos Frameworks

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Web3 Community!

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems BlogBook—Chapter 1: Round 2 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Web3 Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps