Experiencias de programación de Android duramente ganadas

Esta publicación, como dice Kent Beck en su libro Patrones de implementación, "... se basa en una premisa bastante frágil de que un buen código importa ...". Pero todos sabemos que el código limpio es importante ya que hemos tenido que lidiar durante tanto tiempo con su falta. Y también Kent.

Kent Beck

El costo total de poseer un desastre

Hace unos años, como todos los desarrolladores ingenuos de Android que trabajaban en una startup en etapa inicial en la India, traté de "hackear" problemas del mundo real, "perturbar la industria" y hacer mella en el universo. Sin una preocupación en el mundo por el buen diseño o arquitectura de software, comencé a escribir código para crear una aplicación de Android que algún día se convertiría en una de las aplicaciones de cuidado de la salud más grandes de la India.

Sprint tras sprint, hack tras hack, las características se construyeron en una carrera loca. Construir. Medida. Aprender. El tiempo de comercialización era importante y todos los días importaban. El tiempo pasó volando, estábamos creciendo a un ritmo de 1 miembro del equipo cada 6 meses y la aplicación había alcanzado el millón de descargas.

Descargas y clasificación de nuestra tienda Google Play.

En este momento, la aplicación había dejado de ser trivial y se había convertido en un cliente multiinquilino, si eso es algo. Las características que tomarían horas cuando comenzamos ahora tomaban días, a veces semanas. Cada actividad tenía más de 1000 líneas de código de espagueti, ya que Android no se preocupa demasiado por la separación de preocupaciones. El costo total de tener un desastre nos había frenado significativamente.

El enigma de Android

El código se veía feo, las actividades lograron todo:

  • Enhebrar
  • I / O
  • Cálculo
  • Diseños
  • Cambios de configuración
  • Que no

Después de todo, las actividades son controladores, ¿verdad? ¿O son vistas? Ya no lo sabía.

MVC

El gran rediseño en el cielo

Necesitábamos diseñar la aplicación de manera que cambiar una línea de código en algún lugar no rompiera algo en otro lugar. La aplicación tenía que ser, como dice el tío Bob, "robusta pero no rígida, flexible pero no frágil".

Robert

Esto fue cuando mi mentor y amigo Kashif Razzaqui se unió al equipo para ayudarnos a aliviar el desastre. El gran rediseño nunca sucedió, pero refactorizamos nuestro código:

  • Agregamos una capa de "servicio" y movimos todo el código que no es UI, un servicio a la vez.
  • Lanzamos AsyncTasks y nos mudamos a ListenableFutures usando Guava.
  • Descartamos AsyncHttpClient por OkHttp.
  • Pero lo más importante, comenzamos a leer mucho: Código limpio, Arquitectura limpia, SÓLIDO, SECO, El programador pragmático, Concurrencia de Java en la práctica, Diseño dirigido por dominio, etc.

Pronto comenzamos a ver los beneficios de nuestros esfuerzos. La productividad aumentó, estábamos escribiendo cosas más rápido, todos estaban felices.

Esto fue hasta que unificamos nuestras aplicaciones y se rompió todo el infierno. Solo tener una capa de servicio adicional no fue suficiente.

El arte del código limpio

Después de ver los videos del tío Bob sobre Clean Architecture varias veces y leer mucho sobre la arquitectura de la aplicación de Android, decidí experimentar con el patrón de diseño MVP y RxJava.

Unos días después de la experimentación, decidimos cambiar a RxJava e implementar MVP usando Clean Architecture. Nos aseguramos de encapsular todas las capas detrás de las interfaces y separar bien las preocupaciones.

  • La Vista, generalmente implementada por un Fragmento, contiene una referencia al presentador. Lo único que hará la vista es llamar a un método desde el Presentador cada vez que haya una acción de interfaz.
  • El presentador es responsable de actuar como intermediario entre View y Model. Recupera datos del Modelo y los devuelve formateados a la Vista. Pero a diferencia del MVC típico, también decide qué sucede cuando interactúa con la Vista.
  • El modelo es solo la puerta de entrada a la capa de dominio o lógica empresarial.
  • El Interactor se ocupa de E / S y es el proveedor de datos que se mostrarán en la Vista.

Ahora es mucho más fácil cambiar una capa con una implementación completamente nueva. Rediseñar la interfaz de usuario, una parte integral del desarrollo de aplicaciones de Android, se ha vuelto mucho más fácil. Las cosas finalmente pueden moverse rápido sin romperse.

La regla de los Boy Scouts

No es suficiente escribir bien el código, el código debe mantenerse limpio con el tiempo. El hecho de la vida es que el software tiene una tendencia a la entropía. Todos hemos visto que el código se pudre y degrada con el tiempo, así que tomamos prestada la sencilla regla de los boy scouts: "Dejen el campamento más limpio de lo que lo encontraron".

Si todos registramos nuestro código un poco más limpio que cuando lo revisamos, el código simplemente no podría pudrirse. La limpieza no tiene que ser algo grande. Cambie el nombre de una variable para mejor, divida una función que sea demasiado grande, elimine una pequeña duplicación, limpie una instrucción if compuesta.

Conclusión

Nuestra forma de crear una aplicación escalable podría no ser "correcta" y es posible que no esté de acuerdo con esta publicación. Después de todo, no todos los artistas marciales están de acuerdo sobre el mejor arte marcial, o la mejor técnica dentro de uno;)

Hay muchos enfoques diferentes hacia MVP y muchas soluciones interesantes para adaptarlo a Android. El único hecho que no podemos negar es que Clean Code es importante y que no se puede barrer debajo de una alfombra.

Esta publicación toma prestada en gran medida del código limpio del tío Bob y roba el título de la charla Droidcon de Kashif de 2011.

Si Clean Code es importante para usted, hablemos :) Twitter: @_arunsasi LinkedIn: https://www.linkedin.com/in/arunsasidharan

Si te gustó esta publicación, ¡por favor dale al pequeño corazón! ❤