·9 min de lectura
La importancia de la Arquitectura de Software y otras practicas
Si quieres empezar a introducirte en la ingeniera de aplicaciones te recomiendo continuar leyendo
Primero que nada tienes que saber que este no es un post técnico en el sentido de aplicar conocimiento. Mas bien trato de exponer la importancia de la Ingeniería de Software y generar interés. Esto va más allá de aprender el framework o el lenguaje mas demandado del año. Si quieres empezar a introducirte en la ingeniera de aplicaciones te recomiendo continuar leyendo :)
Bueno me gustaría empezar comentando que se suelen ver mejores practicas en el desarrollo de Software en empresas enfocadas en productos, donde se maneja un solo modelo de negocio y tienes la libertad de mejorar el producto de tu empresa. En mi experiencia es mas frecuente y toma mas sentido cuando nuestros desarrolladores solamente se enfocaran en aprender las reglas y políticas de negocio una sola vez. Esto les permite mejorar constantemente el sistema, pensar reiteradas veces en una solución (incluso ya aplicada), refactorizar, proponer, etc. Así que tal vez sean buenos lugares para que te perfecciones como profesional. Solo te lo comento ;)
¿Qué es arquitectura?
Personalmente me gusta definirla de forma breve cómo la forma de controlar la complejidad accidental y mantener la complejidad esencial. Si no entiendes lo que es esto tranquilo, yo tampoco lo hice al principio. Te dejo los conceptos mas abajo:)
Complejidad Accidental: Es todo lo que no fue previsto como parte del desarrollo y que actualmente complica la mantención y extension del sistema. Vamos que esto es lo que te arruina el día, cuantas veces te has creado un programa que empieza facil y termina difícil, o puede que cumpla una función muy básica pero es una lio modificarlo. No lo toques que se cae! un desarrollador con tiempo en el mercado seguramente ha escuchado eso.
Complejidad Esencial: Se puede entender como la complejidad natural de nuestro desarrollo. Cada vez que agregamos nuevas funcionalidades a nuestra aplicación estamos añadiendo complejidad extra, a diferencia de la accidental esta es realizada por necesidad o requerimiento. Ej: agregar una notificación cuando un usuario se suscriba a un post.
La complejidad Esencial es la que deseamos en nuestra aplicación, la accidental es la que debemos disminuir.
¡Ojo! He escuchado a algunos profesionales hablar de la arquitectura de Software como si se tratara de levantar requerimientos, incluso sobre diseño (photoshop y esas cosas) o la maqueta (html, css)… nada mas alejado de la realidad!
Evitando confusiones
Empresas enfocadas en productos, que son las que suelen llevar mejor estas practicas demuestran algunas de las bondades de la arquitectura. Pero quiero dejarte en claro algo para evitar algunas situaciones, no te confundas al ver un sistema que funciona. Las buenas practicas estan escondidas al ojo del espectador. Un equipo de desarrolladores con sólidos conocimientos arquitectónicos estan en el nivel mas alto de un Ingeniero de Software pero aun así no significa que una persona que no tiene conocimientos de arquitectura no cree programas que funcionen bien. La arquitectura respalda el buen funcionamiento de una aplicación, eso esta claro, pero aunque te parezca raro es un papel pasivo en este sentido. El buen funcionamiento básicamente es la consecuencia de hacer las cosas bien para el arquitecto. Retomando el hecho de que existen profesionales con bajo nivel (o nulo) en estos conocimientos, no podemos dejar de lado el hecho de que crean programas que de igual forma funcionan ¿Entonces una aplicación que funciona no es lo mismo que una bien diseñada? Por supuesto que no, y es un error común pensar así. El propósito central de la arquitectura no es que funcionen bien, si no respaldar el ciclo de vida del aplicativo (mantenimiento, fácil comprensión y asegurar un desarrollo continuo). Una aplicación que funciona bien de cara al usuario no significa que este bien diseñada. Una aplicación que esta bien diseñada asegura que cuente con los aspectos del ciclo de vida antes nombrados. Uncle Bob dice “la ultima meta es minimizar el coste de vida del sistema y maximizar la productividad de programador”. Por lo que hablando sobre todo lo dicho se puede inferir que un software que simplemente funcione bien, no significa que funcionara bien al largo de su vida, tampoco que es una aplicación que podrá ser extendida o ampliada con relativa facilidad, menos que es una buena inversión. Aquí es donde las aplicaciones dejan de ser Software y pasan a ser Hardware (algo difícil de modificar). Si no tienes en cuenta esto puedes tirar grandes inversiones a la basura o aumentarlas innecesariamente. Incluso me ha tocado ver empresas al borde de la quiebra por sus malos diseños. No queremos llegar a esto, por eso buscamos una mejor forma de hacer las cosas.
Uncle Bob: la ultima meta es minimizar el coste de vida del sistema y maximizar la productividad de programador.
Sus bondades
La arquitectura juega un rol primordial en los modelos de negocios llevados a aplicaciones, es un reflejo de la propia compañía y su capacidad de adaptación al cambio, es un reflejo de la mejora continua de un modelo rentable que cambia y se adapta a un medio dinámico que es poco previsible. Por esto mismo es que un desarrollo enfocado en una arquitectura nos permite tener una aplicación más sana (tolerable a errores) y escalable (con capacidad de crecer). Y como puedes leer esto no es mas que un resumen de todo lo explicado con anterioridad, pero te dejo algunos puntos extra que logramos con ella:
- Facilidad de desarrollo.
- Baja necesidad de documentación.
- Organización de equipos.
- Aumento en la testeabilidad.
- Aislamiento de errores.
- Disminución de errores.
- Aumento del retorno de inversión (roi).
- Baja deuda técnica.
- Mejor comunicación entre equipos.
- Etc.
Algo del dia a dia
Espero haberte dejado una idea clara de lo que se trata todo esto, de que es lo que buscamos. Ahora ya terminado te mostrare algunos problemas que se suelen topar y que pueden ser solventados por decisiones arquitectónicas y buenas practicas:
- Nadie recuerda su código ni por qué lo hizo. Incluso si recuerdas normalmente es una imagen baga o difusa con poco contexto de lo que realmente trata. Esto esta mas que dicho pero al parecer nunca es suficiente volver a repetirlo.
- Nadie recuerda con exactitud el objetivo de negocio por el que fue construida la aplicación. Aquí el problema es que ya no podemos contrastar nuestras ideas sobre la aplicación con la finalidad de la aplicación.
- Muchas personas tocando el código. Es normal que muchos desarrolladores toquen una aplicación he incluso es muy posible que el equipo original nunca más vuelva a trabajar en la aplicación. Esto no debería ser un problema. Pero si no se tiene conciencia de las practicas que se aplican en el desarrollo ¿Cómo traspasamos conocimiento a los nuevos devs? o ¿como hacemos que sigan la guía de estilo del anterior equipo si nunca estuvo definida? Ahí tienes preguntas que te introducirán si o si a este mundo. Si te das cuenta, esto suele ser una excusa para explicar por que un aplicativo legado se encuentra en tan mal estado.
- Es mas fácil entender el funcionamiento aplicando prueba y error que leyendo el código del aplicativo ¿Te ha pasado? Aquí hago una paréntesis, un buen desarrollador no depende del prueba y error, esto debe ser bajado al mínimo ¿por qué? por qué debemos entender lo que hacemos, simplemente.
- El código esta escrito a la forma y semejanza de cada programador… esto es un lio, se piensa que no se puede controlar pero la verdad es que sí se puede. Una buena forma de solucionar esto es usando patrones.
- etc…
Un buen profesional del software no depende del prueba y error, esto debe ser bajado al mínimo.
Teniendo estos puntos en cuenta ¿cómo podríamos solventarlos? Para esto quiero recordar unas palabras de Robert C. Martin. El dice en su libro Clean Arquithecture “un buen diseño debe gritar de que trata el negocio”. Si es un negocio de ventas nuestro proyecto debe gritar: Soy un sistema de ventas! de esta forma no será necesario asignar grandes cantidades de tiempo para investigación, solo veras las clases, nombres, implementaciones, contratos, test, los casos de uso, etc. De esta forma entenderás el proyecto. Así trabajan los grandes (con poca incertidumbre) y nosotros debemos querer trabajar como ellos.
Las buenas practicas como Clean Code, principios como SOLID, DRY, patrones de diseño, etc. Son los que llevan a solucionar todos estos típicos problemas en el desarrollo de aplicaciones. Como recomendación personal para empezar a mejorar la calidad te recomiendo aprender patrones de diseño ya que son soluciones a problemas repetitivos que te ayudaran a reducir la complejidad de lo que creas o ya has creado.
Divulgando información
Como te dije al principio este no es un post técnico en el sentido de que no enseñare a aplicar nada, así que no hablare de tal patrón y de que forma implementarlo pero si te dejare los mas comunes para que puedas investigar y aprender por tu propia cuenta, entre otras cosas que sé te ayudaran:
Patrones
- Patron Factory
- Patron Builder
- Patron Criteria
- Patron Estrategia
- Patron Repositorio
- Patron Decorador
- Patron Prototipo
- Patron Adaptador
- Patron Template Method
Tipos de programación y estilos de código
- Programación Imperativa.
- Programación Declarativa.
- Programación Funcional.
Arquitecturas de software
- Aplicaciones Monoliticas
- Aplicaciones Isomórficas o Universales
- Microservicios
- CQRS (avanzado)
- Arquitectura hexagonal (avanzado)
- DDD (avanzado)
Recomendación: Estudia sobre arquitecturas limpias.
Principios para hacer aplicaciones aun mejores. Estos son esenciales, no puedes no saberlos!
- Los 12 factores de una aplicación (https://12factor.net). Esto es muy importante! de verdad que es una genialidad.
- SOLID (como dato curioso su contrario es STUPID).
- DRY.
- KISS.
Libros, en este caso solo te recomendare uno. En otros post publicare una recomendación de libros que considero muy valiosos.
- Clean Code. (El libro que todo desarrollador debería leer)
Extra
Por ultimo es importante recalcar que la arquitectura es neutral y agnóstica a la tecnologia que estas utilizando, a diferencia del fraemwork de turno estos conocimientos perduraran con total seguridad en el tiempo. Por esto es que los buenos dev hacen programas tan buenos en python como en java. Si crees que la herramienta hace al profesional estas muy equivocado.
Los buenos dev hacen programas tan buenos en python como en java
Despedida
Cree este post a modo de divulgación para que puedas buscar y aprender por tu propia cuenta algo que ya de por si tiene mucha información publicada por excelentes profesionales y que de verdad creo que te llevaran al siguiente nivel si es que no las conoces. El estudio de esto me llevo a ser un mejor profesional por lo que quiero compartirlo contigo.
Espero que sea de gran ayuda en tu carrera y que tengas éxito en todo.
Referencias
Este articulo fue originalmente escrito en Medium, puedes revisarlo aquí -> https://medium.com/@esteban03/la-importancia-de-la-arquitectura-y-otras-practicas-ef320f631b4f