Mobile – Consejos, Revisión y Aceptación de PRs para Flutter

Hola, como estan, espero que bien 🙂 yo aqui escuchando como suena el techo por la fuerte lluvia jaja, pero bueno hoy les traigo unos consejos que pueden implementar en su equipo de trabajo, o en su trabajo diario.

Code Review Flutter Mobile

Una revisión de código o Code Review, es el proceso mediante el cual los distintos miembros de un equipo revisan en conjunto la implementación realizada por otro miembro para una historia de usuario, aportando ideas sobre mejoras en la implementación, posibles refactorizaciones, discusión de posibles bugs, optimizaciones, errores o mejoras de arquitectura, conveniencia o falta de cobertura de test, y todo tipo de discusiones sobre los cambios realizados para entregar una determinada funcionalidad. Los beneficios de estas revisiones de código van, desde mejorar la calidad del código escrito y el crecimiento profesional de los desarrolladores, hasta ver cómo otros compañeros solucionan problemas concretos e incluso el compartir conocimientos. El objetivo final de una revisión de código debe ser el de determinar qué se está haciendo bien para seguir haciéndolo y qué se puede mejorar.

Formato y Sintaxis

Muchas de las reglas aquí listadas ya se encuentran en el Linter, sólo recuerda seguirlas, por lo cual es recomendable siempre echarle un vistazo a la pestaña de problemas, ésta nos da mensajes informativos en caso de que estemos violando una regla.

• El nombre de las clases, enums, y extensiones debe estar en UpperCamelCase.
• El nombre de los archivos dentro de la carpeta lib deben estar en snake_case
• El nombre de la clase tiene que ser acorde al nombre del archivo, por ejemplo
  • Nombre del archivo: home_view.dart
  • Nombre de la clase: HomeView
• Usar const y final siempre que sea posible.
• Borrar los prints que se hayan usado para depurar.
• Eliminar código que haya sido comentado.
• Evitar cadenas estáticas / codificadas de forma rígida en las pantallas de la interfaz de usuario. Las constantes deben derivarse de un solo lugar, incluidos los códigos de color, los mensajes de validación, etc., todos guardados en el archivo de constantes.
• dart.lineLength debe estar configurado en 100

Arquitectura de Software

La aplicación que se este realizando puede usar clean como arquitectura, Presentación con viewmodels, Dominio con casos de uso y Data con repositorios.

• Las funciones deben ser lo más pequeñas posibles, esto facilita el testing.
• Los widgets deben de ir en la carpeta ui.
  • Los widgets reutilizables se guardan en la carpeta widgets dentro de ui.
• Casos de uso van en la carpeta usecases dentro de domain.
• Modelos van en la carpeta models dentro de domain.
• Repositorios van en la carpeta repositorios dentro de data.
• El nombre de los repositorios debe hacer referencia a la funcionalidad que tiene, no a la tecnología que se usará, por ejemplo.
  • Correcto: NotificationRepository
  • Incorrecto: FirebaseRepository

Testing

El testing es una parte importante para asegurar el correcto funcionamiento en una aplicación, por lo cual toda la funcionalidad que se desarrolle debe tener unit testing, en un futuro se planea integrar widget testing.

• Los archivos se almacenarán dentro de la carpeta test.
• Los archivos deben tener el mismo nombre del archivo que se desea probar añadiendo _test al final, por ejemplo:

counter_app/
  lib/
    counter_app.dart
  test/
    counter_test.dart

• Llamados a funcionalidad externa debe ser a través de un mock.
• Los mocks se almacenan en la carpeta mocks.
• Una funcionalidad con 2 posibles escenarios o más debe crearse en un grupo.
• Todos los tests deben pasar de forma satisfactoria.
• Ejecutar la app y probar la nueva funcionalidad.

Performance

Los llamados a funcionalidad que no ve el usuario debe ser ejecutada en un hilo distinto sin el uso de await, por ejemplo:

• Registro de errores en Crashlytics
• Envío de información a Segment

Provider ViewModel: 

• Si un widget no necesita redibujarse si cambia el estado, éste debe ser llamado de la siguiente manera:

context.read<YoutViewModel>().yourProperty;

Llamados a métodos deben ser llamados de la siguiente manera:

context.read<YoutViewModel>().youtMethod;

Si un widget necesita redibujarse si cambia el estado, éste debe ser llamado a través de un Selector.

Selector<YourViewModel, PropertyType>(
  builder(context, state, child){
    //your state validators
    return child;
  },
  selector(context, vm) => vm.yourProperty,
  child: Container()
);

• Evitar el uso de MediaQuery, en su lugar usar LayoutBuilder para evitar refrescar la pantalla constantemente.
• Si un CustomWidget es usado más de una vez, este debe poder reutilizarse.
• Realizar dispose a los listeners, controllers, streams, etc… cuando éstos dejan de usarse.

Usar ListView.builder para listas en donde no se sabe cuántos elementos tendrá.