Flutter - Construire un projet standard parfait à partir de zéro. Partie 2 : Point douloureux

Crédit : Nguyễn Thành Minh (développeur Android)

À travers cet article, je vais vous présenter 5 points douloureux que j'ai rencontrés en tant que développeur mobile. J'ai formé quelques critères dont nous avons besoin en architecture. Enfin, je vous raconterai également comment Clean Architecture m'a aidé à résoudre ces problèmes.

1. Cinq points douloureux dans le passé

1.1. Les décisions difficiles du chef

Source : Unsplash

Le point douloureux de chaque dirigeant ou architecte vient du fait qu'il doit prendre des décisions.

Le responsable doit décider quel framework, bibliothèque, base de données et technologie ce projet doit utiliser. Une décision hâtive ou un manque de vision entraînera des conséquences imprévisibles dans le processus de développement logiciel. Donc en tant que chef de projet, je suis toujours à la recherche d'une architecture pour m'aider à retarder la prise de décision le plus longtemps possible tout en veillant à ce que l'équipe n'ait pas à attendre que je réfléchisse, mon équipe reste en tête. Même si l'équipe de conception n'a pas encore dessiné d'écrans, notre équipe peut toujours faire la logique en premier et écrire le test unitaire normalement.

1.2. Pendant la maintenance du projet, corriger 1 bogue créera 10 nouveaux bogues

Source : Unsplash

Ce n'est pas inhabituel pour les développeurs lorsqu'ils doivent refactoriser ou corriger un bogue dans un projet avec une "architecture extrêmement collante". Les classes et les fonctions sont si étroitement liées les unes aux autres qu'il suffit de corriger une petite fonction pour faire exploser l'ensemble du projet. Dans certains scénarios, après avoir corrigé 1 bogue, le testeur trouvera 10 bogues supplémentaires, par conséquent, cela peut prendre des mois pour corriger 1 bogue. Cela rend le coût de maintenance du projet très élevé, nous avons donc besoin d'une architecture qui aide à séparer autant que possible les dépendances. Ainsi, chaque fois que nous éditons une classe ou une fonction, l'ensemble du système ne sera pas affecté et vous n'aurez pas à corriger le code manuellement.

1.3. Les points faibles du développeur FE peuvent provenir du développeur BE

Le développeur FE dont le code de classe Model est basé sur la réponse API définie par le développeur BE aura 4 risques :

1. Si BE est mal conçu, FE sera également affecté, le code est très difficile à mapper avec UI, nécessite beaucoup de calculs pour mapper avec UI. Comme l'image ci-dessus, la réponse Json est sur le côté droit, dans le modèle de réservation, il y a un modèle de chambre ; et dans le modèle de chambre, il y a un modèle de réservation, qui ne cesse de se répéter sans fin.
2. Le FE devra s'adapter au BE, mais les classes Model sont importées dans de nombreuses classes comme UI et Bloc. Le corriger entraînera une modification en bloc des classes qui en dépendent.
3. Deux développeurs BE dans une équipe peuvent avoir deux styles de codage différents, ils peuvent donc renvoyer des UserDataréponses très différentes selon les API. Par exemple, dans fetchUsersl'API, ils renvoient le agechamp de type int?, mais dans l' fetchUserDetailAPI, ils le renvoient de type String?. Et si je déclare le champ age de type int?? Mon application plantera lors de l'appel de l' fetchUserDetailAPI. Nous devons donc déclarer le agechamp de type dynamicmême si ce type est considéré comme dangereux car il peut facilement entraîner des erreurs d'exécution. Ce cas est très courant lorsque vous travaillez en tant qu'indépendant lorsque les membres de l'équipe BE n'ont jamais travaillé ensemble auparavant, et qu'il n'y a pas de leaders et que personne ne révise le code.
4. Pour des raisons de sécurité, tous les champs des classes de modèle de données doivent toujours être des types nullables tels que int?, String?. Cependant, cela peut entraîner le risque de plantage de notre application en raison de NullPointerException.

1.4. Créez à la fois l'application mobile et l'application TV sur un seul référentiel

Auparavant, j'ai participé à un projet visant à développer à la fois des applications mobiles et des applications TV comme Youtube. A cette époque, je devais créer 2 modules d'application : mobile_app, et tv_app. Il convient de mentionner ici que ces deux modules utilisent la même API de requête comme fetchVideos, fetchVideoDetail. Ainsi, pour réutiliser le code de la requête API pour les deux modules, nous devons concevoir l'architecture de sorte que la partie API soit séparée dans un autre module à injecter dans ces deux modules d'application.

1.5. L'histoire de la tortue et du lièvre et le sophisme classique du développeur

En regardant deux tableaux statistiques ci-dessus. Les développeurs peuvent le voir comme normal, car c'est quelque chose que nous avons beaucoup rencontré. Mais pour les managers, ils seront certainement concernés. Ils veulent dépenser plus d'argent pour générer des revenus plus élevés et une productivité plus élevée après chaque sortie, mais la vie n'est pas parfaite. En fait, les projets n'ont besoin que de 20% du coût total pour créer 80% des fonctionnalités principales d'un logiciel. Cependant, dans les prochaines versions, ajouter peu à peu peu de fonctionnalités peut coûter très cher, voire dans certains cas provoquer des incidents aux conséquences extrêmement graves. L'architecture a certainement joué un grand rôle dans la cause de ce problème.

Rappelons-nous la leçon sur le lièvre et la tortue que nous avons apprise dans l'enfance. Nous pouvons faire trois leçons pour nous-mêmes :

• Lentement mais surement, on réussit
• La victoire ne dépend pas de votre force ou de votre rapidité
• Plus c'est rapide, moins c'est rapide

Une erreur courante des développeurs est "La date limite du projet approche, codez ce que vous voulez, puis refactorisez-le plus tard". Penser ainsi posera deux problèmes majeurs :

1. Il n'y a pas de temps pour refactoriser. Personnellement, j'ai également expérimenté et vu de nombreux autres développeurs passer leur temps libre le week-end à refactoriser de nouvelles fonctionnalités publiées lors du dernier sprint. C'est une habitude de travail malsaine.
2. Il n'y a aucune assurance que le refactor fonctionnera et ne créera pas plus de bogues.

En conclusion, ce sont mes 5 points faibles que j'ai rencontrés pendant mon temps en tant que développeur mobile. Dans la dernière partie, je révélerai : comment l'architecture propre m'a aidé à résoudre ces problèmes.