clean, architecture, clean architecture, ios, project

¿Qué es una arquitectura limpia y por qué la necesitas en tu proyecto iOS?

Lanzas una versión al Apple Store. Todo va bien hasta que empiezas recibir reviews negativas y te empiezas a poner nervioso. Les pides a tus programadores que te hagan una estimación del tiempo que se tardaría en solucionar. Como tu proyecto no tiene Unit Test configurados, ni sigue una arquitectura limpia, te dan una estimación basada en el tiempo en el que se tardó en resolver un problema similar anteriormente. Pero realmente no están seguros: se tarda bastante tiempo en localizar el fichero exacto de entre las 100 clases y protocolos de tu proyecto, la función correcta, el bucle específico, y la línea de código maldita. ¿Te suena?

El problema: MVC

No te sientas culpable por que tu proyecto no se está usando una arquitectura limpia. Soy de la opinión de que el principal problema es que Apple nos ha regalado una arquitectura de diseño de software demasiado acoplada a la vista y poco testeable. Pero no sólo eso: cuando buscas recursos en Internet, tutoriales o guías de desarrollo de nuevas funcionalidades, te encuentras con que todas siguen en mismo patrón, la misma no-arquitectura. ¿Y qué haces? Pues lo que hace todo el mundo: copiar y pegar en el ViewController. Pues bien, nunca más.

¿Qué es Clean Architecture?

Imagen de arquitectura clean architecture, por Uncle Bob.

No existe una única arquitectura limpia, pero todas ellas se basan en el mismo principio de diseño de software: La separación de responsabilidades. Se establece una arquitectura por capas, cada una de ellas con una responsabilidad específica. Puedes encontrar más información (en inglés) en el artículo de Uncle Bob, desde el cual he enlazado la foto de esta sección.

Gracias a esta separación se consiguen sistemas:

  • Independientes de librerías de terceros
  • Testables
  • Independientes de la vista
  • Independientes de la tecnología de base de datos
  • Independientes de agentes exteriores

 

5 motivos por los que necesitas establecer una arquitectura limpia en tu proyecto iOS

Una Clean Architecture te permite, dejando la lógica de negocio intacta y testeable, sustituir todos los extremos del sistema (base de datos, APIs remotas, vistas, etc…) por mocks o por otras implementaciones concretas.

En el caso de apps para iOS, veo otras ventajas como:

1. Iterar/evolucionar más rápido tu producto. Cada módulo se responsabiliza uno o varios casos de uso relacionados. ¿Tienes un problema en un módulo concreto? Busca tu problema en los ficheros relacionados con ese módulo (en concreto en sus tests).

2. Activar y desactivar funcionalidades y módulos es más rápido. Al tener localizados todos los ficheros de un módulo en un único punto en tu proyecto, la activación y desactivación de determinadas funcionalidades es más rápida (incluso se puede hacer con un flag en el servidor).

3. Habilitar unit tests, y técnicas de análisis del código. Si has probado a hacer Unit Tests en iOS, verás que no es precisamente un camino de rosas, y además, hay que dar con el stack tecnológico adecuado. Pero aún así, te va a permitir:

Ganar confianza. Tras cada cambio subido al servidor, como responsable técnico te sientes respaldado, sabiendo que los nuevos cambios no provocan fallos en lo que ya funcionaba.

Localizar y corregir errores más rápido. Un test case debería ser la especificación funcional de un módulo. Si tienes un problema en un módulo, el primer sitio donde mirar son los ficheros de test case.

Establecer regresiones. Puedes añadir tests a medida que vas encontrando errores en el código para asegurarte de que no vuelvan a ocurrir.

Evitar perder tiempo en debuggear o lanzar la app desde el principio tras cada cambio. Un caso de uso puede tener diferentes variantes y ramificaciones que podemos no ver desde un principio. Por ejemplo, en un caso de uso de Login con Facebook contra un servidor de terceros, se pueden dar media docena de casos de error que tienes que tratar y reproducir a mano si no dispones de los tests adecuados.

4. Conseguir código es manejable, mantenible y flexible a largo plazo.

5. Hay directrices claras en el equipo sobre cómo programar. Las arquitecturas marcan las directrices en las que un programador debe fijarse para introducir nuevas funcionalidades en la app. Es relativamente sencillo hacer que un nuevo developer aprenda dichas directrices si tienes una arquitectura definida.

Empieza ya con una arquitectura limpia

Si quieres atajar los problemas expuestos en el principio de este post, no esperes más. Acumular deuda técnica no te va a ayudar a nada más que a duplicar código innecesariamente, tener que debuggear para buscar cada error, etc.

En iOS tienes varias arquitecturas limpias a tu disposición, cada una con sus ventajas y sus inconvenientes; MVP, MVVM, VIPER entre otras.

¿Y tú? ¿Utilizas alguna arquitectura limpia en tu proyecto iOS? ¿Cuál? ¿O usas una no-arquitectura? ¿Fomentas el uso de unit tests en tu equipo? ¡Cuéntamelo en los comentarios!

 

No hay comentarios

Deja un comentario