Cargando...
La innovación, nuestra razón de ser
Uno de los aspectos que más me preocupa no es sólo el cómo hacemos las cosas sino el porqué y, esa, es una cuestión bastante más complicada de lo que parece a simple vista. A fin de cuentas, podemos hacer algo porque es la forma en la que nos enseñaron, porque se hace así en el sector en el que trabajamos o incluso porque esta de moda. Todo ello son respuestas válidas, hasta cierto punto, pero, en realidad, no nos enfocamos el problema real. Lo que hacemos es para permitir que otro logre sus objetivos de negocio. Por tanto, la respuesta debería ser hacemos lo que hacemos para resolver un problema de negocio.
La pregunta, y su respuesta, son comunes a varios sectores y el del software, lógicamente, es uno de ellos. A decir verdad estamos tan acostumbrados a hablar de principios SOLID, de testing y de tantas otras cosas que se nos olvida que sólo lo hacemos desde un punto de vista técnico. Pero, ¿nos hemos planteado alguna vez como una arquitectura software puede ayudar al negocio a obtener sus objetivos? A fin de proporcionaros un ejemplo me voy a centrar en dos tipos de negocio diferentes.
Además, se debe tener en cuenta que cuando desarrollamos software siempre desarrollamos producto, incluso si trabajamos para una consultora o una software factory. A fin de cuentas, aunque no sea tu producto si lo es el de tu cliente.
Así pues, el software debe desarrollarse de una forma en la que se puedan garantizar estas necesidades, y que, como bien conocéis, se engloban bajo el acrónimo SOLID. Éste aunque incluye muchos principios e ideas, aunque si nos centramos de forma exclusiva en el negocio yo destacaría aquellas relacionadas con la extensibilidad y la dependencia en abstracciones.
En realidad, ambas características están íntimamente ligadas, tanto en el caso del backend como en el del frontend, si bien la forma de hacerlo y lo claro que sea la detección del mismo van a depender enormemente del lenguaje y del framework empleado.
Si nos centramos en el aspecto técnico, la cuestión no es, por tanto, si usamos anotaciones, Spring Boot IoC, Angular IoC o la tecnología concreta que sea. Sino si estas herramientas proporcionadas por cada uno de los framework son suficiente para lograr los objetivos de negocio autoimpuestos.
Así pues, ¿es suficiente una anotación @Autowire para decidir que implementación utilizar? ¿necesitamos algo más? ¿Cómo vamos a resolver todo esto dentro de nuestra arquitectura de software?
Cada caso requiere, probablemente, sus propias respuestas, así que me voy a limitar a daros unas pinceladas de que se puede hacer para resolver estos problemas.
La verdad es que depender solo de anotaciones estándar no es suficiente. Aunque estos mecanismos de autowiring parecen magia se limitan a seguir una serie de reglas preestablecidas. Así pues, usarlos adecuadamente para satisfacer los objetivos de negocio, requiere considerar:
Hablar de "antiguos" sistemas de front es hablar de páginas PHP, JSP o incluso plantillas ERB, en todas ellas no tenemos un framework JavaScript moderno "dando vueltas", sino que la vista se pinta desde el "servidor". No obstante ser "antiguo" no significa que estos problemas no se hayan planteado ni se hayan resuelto.
Así, algunos frameworks como RoR proporcionan un mecanismo de extensibilidad sobresaliente, productos como Drupal o WordPress tienen la extensibilidad en mente, mientras que en otros casos se debe incluir el mecanismo de una forma más manual. En cualquier caso, deberían cubrirse los siguientes aspectos:
Los problemas no desparecen cuando utilizamos una nueva tecnología, de hecho en algunas ocasiones se hacen más intensos. Desarrollar un framework con una nueva tecnología como React o Angular implica que los problemas los debemos resolver de una forma distinta, a decir verdad más parecida a cómo se hace en backend que a los viejos sistemas de frontend.
Por centrarnos, en los sistemas de frontend "antiguos" la responsabilidad de que vista cargar dependía del "framework global", que podía elegir, entre varias, la más adecuada para ejecutar una determinada tarea. Hoy en día, la responsabilidad recae, en el frontend, convertido así en el único responsable de proporcionar los mecanismos de extensibilidad adecuados (esto es matizable, pero dejémoslo estar así).
Qué debemos hacer
