Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

La phase de développement est donc bien souvent la partie la plus longue et la plus coûteuse de la production d’une application mobile. C’est une phase qui implique souvent plusieurs développeurs sur de longues périodes. Si l’on ne fait pas attention, il est possible que cet effort commun se solde par un échec. Cet échec se manifeste souvent par du code désorganisé et qui devient de plus en plus difficile à maintenir. Il se produit une sorte d’effet boule de neige qui fait que le projet prend de plus en plus de retard et coûte de plus en plus cher.

Nous sommes convaincus que pour contourner ce problème, il faut veiller à partir sur des bases solides dès le début du projet. Il ne faut pas partir tête baissée dans le développement du projet sans avoir pris le temps de réfléchir à la structure que l’on va donner au code. Il s’agit de l’architecture du code. En s’assurant que son équipe possède les fondations théoriques et les connaissances pratiques qui vont lui permettre de bien architecturer le code, nous mettons toutes les chances de notre côté afin de mener à bien cette phase de réalisation.

#1 : Les problèmes qui résultent d’un code mal architecturé

Il est souvent difficile de se rendre compte qu’il y a un problème lors de la réalisation de son projet avant qu’il ne soit trop tard, et que le mal soit fait. Le problème principal, et que l’on va appeler la viscosité, se manifeste souvent par des estimations qui s’allongent au fil du temps, ou bien encore des difficultés de plus en plus élevées à faire des modifications ou à introduire de nouvelles fonctionnalités dans un code existant. Les causes de la viscosité sont multiples, mais la plus importante est un couplage fort entre ses différents composants, que ce soit les classes, les interfaces ou les modules. C’est à dire qu’il y a beaucoup de dépendances entre les différents composants et que la responsabilité de chaque composant n’est pas bien établie.

Pour palier ces problèmes de couplage et de viscosité, il faut bien architecturer son code. Comme l’a évoqué Martin Fowler dans son article Design Stamina Hypothesis [en anglais],un code bien architecturé permet de résoudre le problème de la viscosité et de garder de l’efficacité tout au long du développement.

Graphique de Martin Fowler sur les efforts investis en design

Cependant, “bien designer son code” ne se limite pas à simplement choisir une architecture. En effet, il faut faire attention à bien maîtriser les concepts théoriques afin d’appliquer l’architecture choisie de la bonne façon. La phase de réalisation d’un projet peut s’apparenter à la construction d’une maison. Choisir une architecture revient à décider qu’il faut suivre un plan, et ne pas commencer la construction avant d’avoir décidé quoi construire et dans quel ordre. Mais un plan ne peut pas se faire n’importe comment, un architecte qui réalise le plan doit se baser sur plusieurs règles théoriques qui permettent d’assurer le fait que la maison peut tenir debout. En soi, le plan en lui même n’est pas très important, plusieurs plans similaires peuvent donner des maisons qui se ressemblent. Par contre, un plan qui ne répond pas aux règles va toujours donner une maison instable. C’est pourquoi nous mettons l’accent sur ces règles théoriques sous-jacentes quelle que soit l’architecture choisie.

#2 : Les principes théoriques que tout développeur doit connaître

Les développeurs parmi vous auront sûrement déjà vu passer quelques “bonnes pratiques”, souvent sous la forme de recommandations comme par exemple : “utiliser la composition plutôt que l’héritage”. Ces recommandations sont en fait des astuces qui permettent le plus souvent de se conformer à des principes théoriques sans le savoir : les principes SOLID. La compréhension et l’application de ces principes permet de réduire le couplage du code et ainsi sa viscosité. L’exemple cité plus haut est en fait une astuce pour bien appliquer le principe de substitution de Liskov qui explique les contraintes qu’il faut respecter pour utiliser l’héritage entre classes. Il est bien plus efficace de connaître ce que dit le principe plutôt que d’appliquer aveuglément cette astuce.

Bob Martin, qui a introduit ces concepts dans son livre Clean Code, a proposé une architecture qui aide à appliquer ces principes, appelée Clean Architecture.

#3 : Construire un projet d’application mobile… solide

Les principes SOLID représentent la base théorique nécessaire afin de bâtir une maison qui tient debout. Les connaître et savoir bien les appliquer, que ce soit à travers la _Clean Architecture _ou une autre architecture est essentiel si l’on veut s’assurer toutes les chances de réussite lors de la phase de réalisation. L’effet de leur application est un code découplé. Mis à part l’absence de viscosité, le code découplé a aussi d’autres avantages.

Adopter Clean Code, c’est la garantie pour une équipe travaillant sur un projet d’application mobile :

• de pouvoir faire des tests beaucoup plus facilement et tout au long du développement. En effet, le découplage du code permet d’isoler des composants qui autrement ne peuvent qu’être testés conjointement.
• A nouveau, par l’isolation des composants grâce à Clean Code, optimiser la gestion du planning du projet. Cette segmentation diminue la dépendance à des éléments externes, tels que des retards de livraison de maquette ou des difficultés de disponibilité de services techniques.
• Accroître la flexibilité de la gestion des ressources humaines impliquées : plus de développeurs peuvent travailler en parallèle sur des fonctionnalités différentes.