Introduction à l'architecture logicielle

[Menerv]

Depuis un moment déjà, je m'intéresse aux pratiques du test dans le développement et plus précisément au TDD (Test Driven Development). Je ne donnerais pas plus de détails ici car ce n'est pas le sujet de cet article, mais si j'aborde ce sujet c'est parce que je me suis rendu compte que pour pouvoir tester son code comme il convient de le faire, l'architecture de notre code doit permettre d'effectuer ces tests. On dit qu'elle doit être testable.

Ceci étant dit, nous pouvons maintenant nous poser la question de ce qu'est l'architecture de notre projet, et plus globalement ce qu'est une architecture logicielle. Il y a un article complet sur Wikipedia, mais si comme moi tu n'aimes pas les phrases complexes, je la résumerais comme ceci :

L'architecture logicielle est la manière dont sont organisés les éléments structurels de notre code telles que les classes et les fonctions. Il ne s'agit pas de l'implémentation concrète mais de la manière dont ces éléments interagissent entre eux.

Cette définition est très sommaire et elle est sans doute pleines d'omissions mais elle est suffisante pour comprendre le contenu de cet article et là où je souhaite t'emmener.

Maintenant que nous savons de quoi nous parlons, tu peux réfléchir sur l'architecture logicielle de ton projet en cours ou de ton dernier projet. Si tu découvres le concept de l'architecture logicielle avec cet article, je vois deux possibilités :

1. Il n'y a pas de règles spécifiques, tu agences les éléments au jugé et tu les adaptes en fonction de comment le projet évolue; ou bien
2. tu suis des règles que quelqu'un t'as inculqué sans vraiment comprendre les objectifs de celles-ci. En gros tu fais ce qu'on t'as dit parce qu'on t'as dis que c'est comme ça qu'il faut faire.

Que tu sois dans le premier ou dans le deuxième cas n'a pas réellement d'importance, je vais tenter de te partager ce que j'ai appris.

L'architecture logicielle n'est pas un concept récent, il date de la fin des années 1960 mais c'est entre les années 1980 et 1990 que l'architecture logicielle est devenu plus concrète avec, notamment l'apparition de la programmation orientée objet (OOP). La question de l'architecture logicielle s'est posée pour résoudre des problèmes dont certains que tu dois sans doute connaitre. Je vais te raconter deux histoires, des histoires que tu as sans doute vécu :

Aujourd'hui c'est le grand jour, Bob est super excité, il va commencer un nouveau projet et il a hâte de plonger dans le code afin de créer ses premières classes et fonctions.
Rapidement, une première version voit le jour, elle est encore très sommaire et présente peu de fonctionnalités, mais c'est tout à fait normal, après tout Rome ne s'est pas faite en un jour !
Bob décide donc d'agrémenter son logicielle avec des nouvelles fonctionnalités. Aucun problème, il démarre son éditeur de code et rapidement arrive a ajouter ces fonctionnalités.
Le logiciel de Bob continue d'évoluer de semaines en semaines. Etrangement, plus le temps passe, plus l'ajout de nouvelles fonctionnalités prend du temps. Tout devient de plus en plus complexe avec la multiplication des classes et fonctions qui dépendent les unes des autres. L'ajout d'une nouvelle fonctionnalité engendre des chaines d'effets indésirables qu'il faut régler de bout en bout afin que la fonctionnalité soit opérationnelle et sans bogues.
Au fur et à mesure que le temps passe et que la complexité augmente, la motivation diminue jusqu'à ce que Bob souhaite ne plus travailler sur ce projet pour lequel il était si excité au début.

C'est parti, Emilie est prête a démarrer son nouveau projet avec impatience, le projet est très stimulant. Elle ouvre son éditeur de code préféré et commence rapidement a écrire ses premières lignes de code. Au bout d'un moment, elle sort la première version de son logicielle. Emilie est très satisfaite et les retours sont positifs. Elle continue de faire évoluer son logiciel jusqu'au jour où, mince, une librairie qu'Emilie utilise n'est pas compatible avec les évolutions qu'elle souhaite ajouter à son logiciel. La librairie n'étant plus maintenue, elle n'a d'autre choix que de remplacer cette librairie par une autre qu'elle a trouvée et qui répond mieux a son besoin.
Sauf que remplacer la librairie qui pose problème s'avère extrêmement complexe. A telle point qu'Emilie se pose maintenant la question si redévelopper de zéro son logiciel ne serait pas plus rapide que de tenter de modifier son logiciel existant sans garantie de résultat…

Voici deux situations que j'ai personnellement vécu. C'est frustrant, démotivant et si l'on n'a pas de contraintes a réaliser le projet on l'abandonne sinon on travaille sur un projet que l'on se met à détester et les journées deviennent longues et pénibles…

Si Bob et Emilie avaient adopté une bonne architecture logicielle, leur problème n'aurait pas été un problème !

Les règles d'une bonne architecture doivent œuvrer pour atteindre ces objectifs :

• Testabilité
• Maintenabilité
• Evolutivité

Testabilité parce que les tests permettent de refactoriser le code (modifier la forme sans changer la fonctionnalité) en garantissant qu'il n'y a pas de régression (bogues).

Maintenabilité parce qu'il doit être possible d'effectuer des modifications du code en ayant un impact minimum voir nul sur le code qui n'est pas touché.

Evolutivité parce que le projet doit pouvoir continuer d'évoluer sans que la complexité à implémenter des nouvelles fonctionnalités ne soit un facteur bloquant voir ralentissant.

Maintenant que nous avons vu le quoi et le pourquoi de l'architecture logicielle, je te proposerai dans des prochains articles, de répondre au comment !

Mais si tu es trop impatient ou curieux, je t'invite a lire Clean Architecture de Robert C. Martin ou bien à te renseigner sur l'architecture hexagonale (c'est celle que j'ai choisi d'utiliser et que j'aborderai dans les articles suivants).