¿Es posible aplicar Clean Arquitecture en mi empresa?

Ya hace un tiempo hablé de Clean Arquitecture, centrándome en como implementarlo en iOS gracias a VIPER.

Toda la teoría siempre está bien, pero al final siempre tenemos que luchar contra la realidad, y no siempre es fácil aplicar esta solución y hacerle entender a nuestra empresa o nuestros clientes qué es lo mejor para su proyecto.

Por resumir un poco, Clean Arquitecture es una forma de organizar el software definida por Robert C. Martin (Uncle Bob) donde intentaba solucionar una serie de problemas y hacer el código robusto, mantenible, testeable y extensible.

Para ello esta arquitectura tenía que cumplir estos objetivos:

• Independiente de frameworks.
• Testeable.
• Independiente de la UI.
• Independiente de la base de datos.
• Independiente de factores externos.

Como vemos, las dos claves son la independencia de las capas y que sea testeable.

The Clean Arquitecture, by Uncle Bob

Esta arquitectura estaba muy influenciada por SOLID y, además de los puntos destacados antes, algo muy importante son las reglas de dependencia y la comunicación entre capas.

Como he comentado antes, podéis profundizar más sobre esto en el artículo sobre Clean Arquitecture.

Vayamos ahora al objetivo del artículo, ¿es posible usar esta arquitectura en mi empresa, en mi proyecto, con mis clientes?

La respuesta corta es: depende de ti.

Como desarrollador, tú eres el actor más importante del proyecto y es tu obligación no solo que todo funcione según las especificaciones que te dan, si no que funcione con un código robusto, con un código mantenible a lo largo del tiempo y que su calidad sea la más alta que le puedas dar.

Para quien recibirá el proyecto, usar este tipo de arquitecturas les suele sonar a que su coste en tiempo y, por tanto, dinero será mayor, y que la recompensa será la misma. Ahí es donde tenemos nosotros, como desarrolladores, que dar el aviso, la recompensa será mucho mayor aunque no se pueda ver a simple vista.

La primera recompensa será la robustez del código. Al ser más fácilmente testeable, todo estará (o debería estar) con tests y muchos de los errores controlados. Obviamente ningún software está exento de errores, pero esto los minimizará mucho.

Otra recompensa será la mantenibilidad del proyecto. Al estar compuesto por diferentes capas independientes, y sujetas a las reglas de dependencia, si alguna de ellas cambia no afectará al resto y el cambio será lo menos traumático posible. Esto hará al software más adaptable al cambio, tanto a nivel de interfaz, de fuente de datos o de lógica de negocio, lo cual es una gran reducción de costes y tiempo en proyectos de larga duración, que unido a los tests añadidos en el punto anterior hace que el proyecto siga siendo igual de robusto y previniendo posibles errores debido a estos cambios.

El proyecto además será fácilmente extensible a nuevos desarrollos, teniendo la opción de reutilizar gran parte de nuestro código para nuevos objetivos. Si ponemos como ejemplo una aplicación desarrollada para iPhone, si queremos adaptarla a iPad, Apple Watch o AppleTV podríamos reutilizar toda la lógica de negocio y adaptar tan solo las capas de presentación, aprovechando la robustez y mantenibilidad de esa parte y haciendo un desarrollo que podría haber sido de larga duración en una adaptación sencilla, rápida y barata.

Y, al ser el centro de la arquitectura la lógica de negocio, nuestro modelo está mucho más cercano a la definición funcional, siendo más fácil identificar los casos de uso definidos por los requisitos funcionales.

En definitiva, aunque poner los cimientos de esta arquitectura pueda parecer al principio lenta, la curva de velocidad va aumentando a medida que evoluciona el desarrollo y al final tendremos una reducción de costes que irá unido a la calidad del software.

Para ello, y para terminar, hay una serie de consejos que deberíamos seguir para conseguir que esta arquitectura cumpla los objetivos que buscamos, aunque la mayoría de ellos son aplicables a cualquier tipo de desarrollo de software:

• Testea. Si utilizamos una arquitectura que nos facilita enormemente testear, pero no hacemos ningún test, esta ventaja se convierte en una desventaja. No pensemos nunca que no tenemos tiempo para hacer tests, sería un error similar a creer que no tenemos tiempo para aplicar el diseño correcto o la lógica de negocio adecuada. Lo más correcto sería hacer TDD, desarrollar primero los tests y a partir de ellos nuestro código. Parece difícil pero os puedo asegurar que con esta arquitectura es muy fácil y os ayudará a implementar los diferentes casos de uso con mayor rapidez.
• Refactoriza. Ningún desarrollo es perfecto a la primera, y ningún proyecto está al 100% definido desde el primer día, así que a lo largo de la construcción de nuestro software algunos requisitos evolucionarán o cambiarán, y nuestro software se verá afectado. No tengamos miedo a refactorizar, dediquemos el tiempo necesario a ello ya que finalmente será una ventaja para la velocidad y robustez de nuestro código.
• Reutiliza. Este punto va muy unido al anterior, si en cualquier momento vemos que hacemos demasiado copy&paste de algún trozo de código, que repetimos algo en muchos sitios, desarrolla un componente (ya sea visual, de negocio, de acceso a datos) y reutilízalo allá donde lo necesites. Esto reducirá nuestro margen de error y nos ayudará a realizar cambios tan solo utilizando un elemento de nuestro código. Aunque hay que tener cuidado de no hacer un “componente mágico” que sirva para casi todo y empecemos a incumplir varias leyes de SOLID, sobre todo la primera, que nos dice que cada objeto debe tener una y solo una responsabilidad.
• Teoría de las ventanas rotas. No siempre vamos a entrar en un proyecto nuevo donde tener la opción de hacer el desarrollo correcto desde el principio. Muchas veces heredaremos código, heredaremos otros proyectos, y puede que no cumpla nada de lo que hemos hablado aquí. La teoría de las ventanas rotas nos dice que si vemos un edificio que tiene ventanas rotas, no nos importará coger una piedra y romper alguna de las ventanas que aún estén enteras. En cambio, si vemos un edificio con todas las ventanas sin romper no tendremos esa tentación. Extrapolando esta teoría al software, suele pasar que cuando entramos en un proyecto donde todo es un desastre tendemos a seguir aumentando el desastre y a escribir código con la única intención de que siga funcionando, por muchas “ñapas” que tengamos que usar. Es un error, no entremos en un software “rompiendo ventanas”, intentemos que el código que escribamos sea de calidad y consigamos arreglar la mayor parte de software posible. Para saber si lo estamos haciendo bien tan solo tenemos que conseguir que cuando dejemos ese proyecto esté mucho mejor que cuando lo heredamos, y no aún peor.
• Revisa. Es muy útil la revisión de código, tanto el tuyo por parte de tus compañeros como el de tus compañeros por tu parte. Hacer pull requests, o pair programming es de gran utilidad para mejorar nuestro trabajo y aprender y evolucionar como desarrollador. Acepta las críticas de los demás, y aprende a enseñar tus prácticas a tus compañeros.
• Comparte. A lo largo de la vida de un desarrollador, la forma más rápida de aprender y mejorar es gracias a código de terceros que lo han compartido. Haz tú lo mismo, comparte cualquier código que veas de utilidad para la comunidad. Eso ayudará a otros a aprender y mejorar, y a ti para que, como decía en el punto anterior, tú código sea revisado y mejorado.
• Evoluciona. No nos anclemos a una arquitectura y sigamos con ella hasta la muerte. El mundo del software evoluciona, y tenemos que estar preparados para ello, tanto nosotros como nuestro trabajo. Lee, escucha y aprende, y nunca cierres la mente a nuevas metodologías con las que trabajar.

Tuve la oportunidad de dar una pequeña charla de 5 minutos en el pasado KeepCoding Connect sobre este tema, os dejo aquí el video.