VIPER hangout

  3 mins read

El pasado Miércoles 28 estuvimos hablando por hangouts on air Alberto Moraga, Pedro Piñera y yo sobre VIPER y en general arquitectura, os dejo las preguntas que se hicieron contestadas y el video del evento.

¿Qué beneficios habéis visto con este tipo de arquitectura?

  • Poder testar todas tus capas, independientemente de sus dependencias
  • Que tengas claro en todo momento en que capa cae lo que estás haciendo
  • Tener una lógica de dominio sin implementaciones concretas y por lo tanto esté desacoplada de todo
  • Todo el mundo de tu equipo trabaje de la misma forma que tú por lo que el proyecto parece que lo haya programado 1 persona y no 5 distintas
  • Qué todo tu equipo hable usando el mismo idioma y por lo tanto cuando alguien diga por ej “se me ha roto el interactor de login” todo el mundo sepa que está fallando independientemente de la plaforma que use
  • Tener tu código de vista “repartido” en varias clases y no tener 1 sola con 100000 lineas
  • Reusar tus casos de uso todo lo que puedas, sobre todo aquellos que sabes que pueden ser rehusados en varios puntos (logins, etc…)

¿Qué desventajas?

  • Explosión de clases
  • Curva de aprendizaje inicial alta si no has tocado nada nunca de esto
  • Si tienes una app que ya existe el refactor puede ser horroroso.

¿Dónde gestionáis las dependencias? ¿Hacéis inyección de dependencias?

Hacemos inyección de dependencias ya que permite que testemos mejor ciertas clases. Por ejemplo en un Repository que tiene 2 data sources, “NetworkDataSource” y “AmazonDataSource”, inyectamos ambas dependencias desde fuera y nos despreocupas de la implementación concreta en el propio repositorio, lo que da más posibilidades a la hora de testear. También tiene como ventaja que si usamos cualquier framework como Typhoon o Dagger podemos gestionar mejor el ciclo de vida de los objetos y hacerlos Singleton sin tener que manejar ese ciclo desde dentro de los propios objetos, sino que es la app la que configura ese ciclo.

¿Qué estructura suelen tener vuestros módulos?

Esto es una buena pregunta, en mis proyectos intento siempre que cada capa de la arquitectura esté bien reflejada con sus directorios o proyectos independientes. En caso de Android siempre que puedo usar Java lo uso en vez de un modulo Android. Separo siempre que puedo la app en los módulos “app”, “presentation”, “domain”, “data”, “repository”.

¿Hacéis pruebas unitarias de todo?

Para mi este es el punto critico, un software con 100% de coverage es casi imposible además que para mi aporta muy poco, soy de los que tiene la opinión que hay que probar lo justo y necesario para dormir por las noches, es decir, la funcionalidad crítica. Por ej un registro de usuario, login, y la funcionalidad de tu app base.

¿Habéis visto beneficios / desventajas en velocidad a la hora de desarrollar?

Aplicar esta arquitectura no nos vamos a engañar, cuesta un poco más, hay que tener en cuenta que hay que crear más ficheros para hacer una funcionalidad, pero, creo que con el tiempo este tiempo va a ser recuperado ya que trabajamos con clases más pequeñas, más legibles y mejor organizadas. Digamos que a la hora de “crear” si que diría que se tarda un poco más, pero a la hora de “mantener” se tarda bastante menos.

¿Dónde ponéis partes comunes como puedan ser la conexión de red y bases de datos?

Tenemos implementado el patrón repository por lo que un Repository maneja varios origenes de datos. Suelo montar un repository por actor de la app, en el caso de Selltag por ejemplo tenemos un “ProductRepository” que trabaja con origen de red (api) y un origen de bdd (cache).

¿Qué estrategias seguís para el modo offline?

Como he comentado anteriormente es el repository el que maneja de donde vienen los datos por lo que desde la parte de domain/interactor te despreocupas de esas decisiones.

¿Creéis que puede ser un buen primer paso hacia una mejor arquitectura?

Desde luego que si. Este tipo de arquitecturas son las que hacen que un programa a medida que crece se haga más robusto, tenga menos fallos y si entra alguien nuevo al proyecto sea capaz de meterle mano sin romper demasiado. Decir que estas arquitecturas no valen para todo y que hay que estudiar cada caso.

¿Cuánto tiempo creéis que habéis tardado en adaptaros a esta nueva arquitectura y ser igual de rápidos haciendo apps de la forma convencional?

He visto charlas, he leído, he “perdido” tiempo implementadolo en proyectos de ejemplo más pequeño para terminar de convencerme antes de llevarlo a una app en producción, quizá haya tardado entorno a 1mes – 1mes y medio en terminar de adaptarme y comprender donde va cada cosa y mejorar mi estilo. Como he comentado antes, creo que se tarda un poco más, pero a la larga recuperas ese tiempo en mantenimiento y reusabilidad.

Written by:

Christian Panadero Martinez