Flutter — Creando un Proyecto Boilerplate perfecto desde cero. Parte 2: Punto de dolor

Crédito: Nguyễn Thành Minh (desarrollador de Android)

A través de este artículo, les presentaré 5 puntos débiles que he experimentado mientras era desarrollador móvil. He formado algunos criterios que necesitamos en arquitectura. Finalmente, también les contaré la historia de cómo Clean Architecture me ayudó a resolver esos puntos débiles.

1. Cinco puntos débiles en el pasado

1.1. Decisiones difíciles del líder

Fuente: Unsplash

El punto de dolor de cada líder o arquitecto proviene de tener que tomar decisiones.

El líder tiene que decidir qué marco, biblioteca, base de datos y tecnología debe usar este proyecto. Una decisión apresurada o falta de visión traerá consecuencias impredecibles en el proceso de desarrollo de software. Entonces, como líder de proyecto, siempre busco arquitectura que me ayude a retrasar la toma de decisiones el mayor tiempo posible, pero aún así me aseguro de que el equipo no tenga que esperar a que yo piense, mi equipo se mantiene a la vanguardia. Incluso si el equipo de diseño aún no ha dibujado ninguna pantalla, nuestro equipo aún puede hacer la lógica primero y escribir la prueba de unidad normalmente.

1.2. Durante el mantenimiento del proyecto, corregir 1 error creará 10 errores nuevos

Fuente: Unsplash

Esto no es inusual para los desarrolladores cuando tienen que refactorizar o corregir errores en un proyecto con una "arquitectura extremadamente complicada". Las clases y las funciones están tan estrechamente relacionadas entre sí que solo arreglar una pequeña función es suficiente para hacer explotar todo el proyecto. En algunos escenarios, después de corregir 1 error, el evaluador encontrará 10 errores más, por lo tanto, puede llevar meses corregir 1 error. Esto hace que el costo de mantenimiento del proyecto sea muy alto, por lo que necesitamos una arquitectura que ayude a separar las dependencias tanto como sea posible. De modo que cada vez que editemos una clase o una función, no se verá afectado todo el sistema y no tendrás que arreglar el código manualmente.

1.3. Los puntos débiles del desarrollador FE pueden provenir del desarrollador BE

El desarrollador de FE cuyo código de clase de modelo se basa en la respuesta de API definida por el desarrollador de BE tendrá 4 riesgos:

1. Si BE está mal diseñado, FE también se verá afectado, el código es muy difícil de mapear con UI, requiere muchos cálculos para mapear con UI. Como en la imagen de arriba, la Respuesta Json está en el lado derecho, en el modelo de Reserva hay un modelo de Habitación; y en el modelo de Habitación, hay un modelo de Reserva, que sigue repitiéndose sin fin.
2. FE tendrá que adaptarse a BE, pero las clases de modelo se importan a muchas clases como UI y Bloc. Arreglarlo conducirá a la modificación masiva de las clases que dependen de él.
3. Dos desarrolladores de BE en un equipo pueden tener dos estilos de codificación diferentes, por lo que pueden devolver UserDatarespuestas muy diferentes según las API. Por ejemplo, en fetchUsersAPI, devuelven el agecampo de tipo int?, pero en fetchUserDetailAPI, lo devuelven de tipo String?. ¿Qué sucede si declaro el campo de edad de tipo int?? Mi aplicación se bloqueará al llamar a la fetchUserDetailAPI. Por lo tanto, debemos declarar el agecampo de tipo dynamicaunque este tipo no se considere seguro, ya que fácilmente puede generar errores de tiempo de ejecución. Este caso es muy común cuando se trabaja como autónomo cuando los miembros del equipo de BE no han trabajado antes entre sí, y no hay líderes ni nadie revisa el código.
4. Por seguridad, todos los campos de las clases de modelo de datos siempre deben ser tipos que admitan valores NULL, como int?, String?. Sin embargo, esto puede generar el riesgo de que nuestra aplicación se bloquee debido a NullPointerException.

1.4. Cree tanto la aplicación móvil como la aplicación de TV en un repositorio

Anteriormente, participé en un proyecto para desarrollar aplicaciones móviles y de TV como Youtube. En ese momento, tuve que crear 2 módulos de aplicaciones: mobile_app, y tv_app. Vale la pena mencionar aquí que estos dos módulos usan la misma API de solicitud como fetchVideos, fetchVideoDetail. Por lo tanto, para reutilizar el código de la solicitud de la API para ambos módulos, debemos diseñar la arquitectura para que la parte de la API se separe en otro módulo para inyectar en esos dos módulos de la aplicación.

1.5. La historia de la liebre y la tortuga y la falacia clásica del desarrollador

Mirando dos gráficos estadísticos arriba. Los desarrolladores pueden verlo como algo normal, ya que esto es algo con lo que nos hemos encontrado mucho. Pero para los gerentes, ciertamente estarán preocupados. Quieren gastar más dinero para generar mayores ingresos y una mayor productividad después de cada lanzamiento, pero la vida no es perfecta. De hecho, los proyectos solo necesitan el 20% del costo total para crear el 80% de las características principales de un software. Sin embargo, en las próximas versiones, agregar algunas funciones poco a poco puede costar mucho, en algunos casos, incluso puede causar incidentes con consecuencias extremadamente graves. La arquitectura ciertamente jugó un papel importante en la causa de este problema.

Recordemos la lección sobre la liebre y la tortuga que aprendimos en la infancia. Podemos llevar a cabo tres lecciones para nosotros mismos:

• Lento y constante gana la carrera
• La victoria no depende de lo fuerte o rápido que seas
• A más prisa, menos velocidad.

Una falacia común de los desarrolladores es "Se acerca la fecha límite del proyecto, codifica lo que quieras, luego refactorízalo más tarde". Pensar así traerá dos grandes problemas:

1. No hay tiempo para refactorizar. Personalmente, también he experimentado y visto a muchos otros desarrolladores pasar su tiempo libre los fines de semana para refactorizar las nuevas funciones lanzadas en el último sprint. Este es un hábito de trabajo poco saludable.
2. No hay garantía de que el refactor funcione y no cree más errores.

En conclusión, estos son mis 5 puntos débiles que he encontrado durante mi tiempo como desarrollador móvil. En la última parte, revelaré: ¿Cómo me ayudó Clean Architecture a resolver estos puntos débiles?