L'importance des architectures modulaires dans les applications mobiles

Importance de l'architecture technique dans le développement d'applications mobiles

Lorsqu'on développe une application mobile, il est important de bien concevoir son architecture technique dès le début. Souvent, de nombreuses entreprises se concentrent uniquement sur des aspects tels que l'expérience utilisateur, l'ergonomie ou le design, mais elles négligent souvent la qualité du code ou des concepts comme la maintenabilité et l'évolutivité, entre autres.

Le résultat est une application qui répond initialement aux attentes de l'entreprise elle-même ainsi que des utilisateurs finaux, mais qui à long terme devient difficile à maintenir, difficile à étendre avec de nouvelles fonctionnalités et un projet sur lequel personne ne veut travailler. Dans cet article, nous allons essayer d'analyser ces situations et comment tenter de les éviter.

Qu'est-ce que l'architecture d'une application mobile ?

Une architecture est un ensemble d'éléments et de décisions qui définissent comment doit être (et évoluer) la structure interne du code d'une application. Ce concept n'est pas spécifique aux applications mobiles mais est présent depuis de nombreuses années dans de nombreux projets logiciels de toute technologie.

Dans le cas concret des applications pour iOS et Android, une architecture est la manière dont sont structurées les différentes vues, le code associé à celles-ci, les ressources graphiques, la logique métier, les modèles de données, la communication avec les services et bases de données et la persistance des données, entre autres. Elle décrit également comment doivent communiquer les différents éléments qui font partie de la structure d'une application.

Il est assez courant que dans les applications mobiles, la conception technique ne soit pas autant prise en compte et que d'autres aspects soient privilégiés. Il est important de ne pas négliger comment une architecture modulaire peut bénéficier à une application mobile si le projet est de taille moyenne. Dans le cas d'applications plus petites, l'utilisation de ce type d'architectures serait considérée comme une sur-ingénierie.

Pourquoi faut-il prendre en compte l'architecture dès le début ?

Pour comprendre cela, le mieux est d'utiliser un exemple de la vie quotidienne : imaginons que vous venez d'acquérir un terrain et que vous souhaitez y construire une maison. Aujourd'hui, il existe une grande variété d'options : maisons préfabriquées, par modules, construction traditionnelle, etc.

Lorsqu'on se prépare à construire une maison ou à en acheter une déjà construite, on prête attention à plusieurs aspects tels que : le type de matériaux qui seront utilisés, leur qualité, le coût qu'ils représentent pour l'ensemble de l'ouvrage, leur durabilité et d'autres sujets d'intérêt plus ou moins important.

Selon les choix que nous faisons, la maison que nous construisons sera une maison de luxe ou une maison normale, durera 10 ans ou durera 200 ans, etc. Cela ne signifie pas que l'une est meilleure que l'autre, mais nous devons tenir compte du nombre d'années que nous voulons y vivre ou si nous envisageons de la rénover complètement avec le temps. Nous devons nous assurer que le projet répond à nos attentes.

Si nous nous concentrons uniquement sur l'esthétique et la fonctionnalité sans prendre en compte des éléments clés tels que les fondations, la qualité des murs, etc., nous aurons probablement de graves problèmes au fur et à mesure que nous passerons du temps dans cette maison : humidité, bruits extérieurs, fuites... et une multitude de problèmes.

Peux-tu imaginer une maison où les toilettes se trouvent dans la cuisine et la salle de bain a un four ? Il est certain que tu ne vivrais pas dans cette maison ou au minimum tu ne pourrais pas l'appeler un foyer. Mais avec un code, nous ne sommes pas capables de voir ces choses si nous n'avons pas de connaissances techniques ; il est probable que dans ton application, tu aies un four dans la salle de bain.

Nous pouvons avoir une application qui soit belle et fonctionnelle pour son lancement, mais à l'intérieur, le code peut ne pas être optimal et avoir de nombreuses fonctionnalités couplées. Dans ce scénario, étendre ce même code avec de nouvelles fonctions ou le maintenir et rechercher ses erreurs pour les résoudre devient de plus en plus une tâche difficile. En suivant l'exemple précédent, déplacer les toilettes dans la salle de bain et le four dans la cuisine n'est pas aussi simple que de déplacer les éléments, mais nécessite de changer une grande partie de l'installation.

C'est un facteur qui impacte non seulement le projet mais aussi la rotation du personnel technique.

L'impact de la rotation sur les projets

Que les architectures ne soient pas bien pensées dès le début ne provoque pas seulement des problèmes pour les développeurs, mais aussi pour les entreprises elles-mêmes. Lorsqu'un projet n'a pas été bien conçu dès le départ et que l'on demande à quelqu'un de continuer à en étendre le fonctionnement, cela finit par générer de la frustration car les choses vont de plus en plus mal. Il est très difficile de structurer quelque chose qui était mal conçu au départ, peu importe le nombre d'heures consacrées à refactoriser le code et à réécrire certaines parties.

Cette frustration se termine souvent par des problèmes entre les membres de l'équipe (généralement entre les personnes techniques et non techniques), en raison de l'incapacité à transmettre et à faire comprendre aux parties prenantes que l'architecture de l'application n'a pas été bien conçue dès le départ. En fin de compte, comme tout dans la vie, lorsque quelque chose ne fonctionne pas, cela finit par se briser complètement et les gens finissent par partir. Chaque fois qu'une personne de l'équipe s'en va, non seulement une ressource s'en va, mais tout le savoir et l'expérience de cette personne s'en vont également.

Il est courant de penser qu'avec une personne plus senior ou plus expérimentée, nous résoudrons le problème, car elle réécrira les parties de code qui ne sont pas correctes et ainsi il n'y aura plus de frustration. Mais généralement, c'est l'effet inverse qui se produit : plus un professionnel a d'expérience, plus il se rend facilement compte des problèmes structurels d'une application et il finira probablement par abandonner le navire avant un profil plus junior, qui mettra plus de temps à percevoir la situation.

C'est un poisson qui se mord la queue, tandis que les utilisateurs finaux continuent d'attendre des mises à jour avec de nouvelles fonctionnalités et des corrections de bugs qui n'arrivent jamais.

Que pouvons-nous faire pour améliorer ces situations ?

La seule solution possible est de réécrire entièrement l'application, mais en changeant le processus. Si vous n'avez pas pris en compte la conception technique au début du projet, c'est le moment de le faire si vous décidez de repartir de zéro. Si vous essayez de réécrire des parties ou de résoudre quelques petits défauts, la base du problème sera toujours là. C'est comme essayer de résoudre un problème de cohabitation sans que les deux parties reconnaissent sincèrement leurs erreurs, il réapparaîtra avec le temps.

Aujourd'hui, il y a une tendance en plein essor : les architectures modulaires. Ce n'est pas une simple mode passagère, car les architectures modulaires viennent résoudre deux problèmes principaux : la maintenabilité et la scalabilité. Voyons comment elles y parviennent.

Qu'est-ce qu'une architecture modulaire ?

Une architecture modulaire est celle qui permet de diviser une application en plusieurs modules. Un module est un sous-ensemble d'une application qui a :

• Une responsabilité unique, une seule
• Un comportement fonctionnel déterminé et aucun autre
• La capacité de communiquer avec d'autres modules sans les connaître complètement
• La capacité de changer son intérieur sans affecter l'extérieur

Ce type d'architectures utilise une technique appelée diviser pour régner, qui consiste à diviser un très gros problème (une grande application) en fragments très petits et spécifiques. De cette manière, chaque fois qu'un de ces modules est créé, c'est comme commencer un projet à partir de zéro : si quelque chose ne fonctionne pas bien, vous pouvez le refaire.

La principale différence avec une architecture traditionnelle est que les différents modules peuvent être utilisés et communiquer entre eux, mais ne doivent pas se connaître. De cette manière, il est relativement facile de remplacer une pièce qui ne fonctionne pas par une autre, car les autres pièces sauront immédiatement comment communiquer avec la nouvelle. D'un point de vue technique, la description de cette architecture est dite suivre les principes SOLID, dont vous avez sûrement déjà entendu parler.

Avantages et Inconvénients des architectures modulaires

Comme tout dans la vie, les architectures modulaires ont des avantages mais aussi des inconvénients. Voyons lesquels :

Avantages les plus pertinents

• Permettent de refaire des parties qui ne fonctionnent pas sans affecter le reste.
• Permettent de paralléliser davantage le développement une fois que la base technique est établie.
• Facilitent la maintenance en étant divisées en pièces plus petites et moins complexes.
• Améliorent le bonheur de l'équipe à long terme car elles ne génèrent pas autant de frustration.
• Permettent de s'adapter rapidement aux nouvelles fonctionnalités des systèmes d'exploitation (par exemple, les "App Clips" récemment annoncés par Apple).

Inconvénients les plus pertinents

• Exigent un effort initial plus important : l'investissement économique nécessaire par rapport à une architecture traditionnelle est beaucoup plus élevé. Principalement parce qu'il faut des profils avec beaucoup d'expérience et il faut consacrer beaucoup de temps à rédiger de la documentation technique et à réaliser des analyses techniques complexes qui apportent des solutions aux besoins de l'entreprise à long terme.
• Exigent une surveillance constante : pour éviter que l'approche initiale ne soit déformée, il est essentiel de surveiller périodiquement l'état du code, de s'assurer que les directives fixées sont respectées, etc. Les équipes qui effectuent ces tâches sont généralement appelées bureaux techniques. Il n'est pas nécessaire qu'elles soient composées de nombreuses personnes, mais il est strictement nécessaire qu'elles existent.