Cet article est le troisième article d’une série sur les architectures logicielles agiles. Il fait suite à une introduction sur les concepts de l’architecture logicielle et à une étude détaillée de l’architecture avant-projet “just enough up front design”.

Nous allons à présent vous parler du cœur de la pratique du design émergent (“emergent design” en anglais) : l’architecture pendant la phase de développement. Cette partie sera donc un peu plus technique que les précédentes, mais souhaite vous rester accessible même si vous êtes non développeur.

Définition de l’emergent design

Comme définie dans l’article d’introduction, la notion de design émergent vient du fait que l’architecture de votre application va être définie au fil de l’eau, pendant sa création. Ce concept a été appelé “simple design” au moment de sa définition au sein du mouvement de l’XP programming mais le terme de “simple” étant mal compris, il a été renommé en : “emergent design”.

Il se pratique via une série d’étapes : les développeurs codent une fonctionnalité A puis une fonctionnalité B. Après cela ils identifient les éléments communs à A et B pour les factoriser (cette étape est nommée “refactorisation”). L’idée est donc de supprimer toute duplication de fonction au sein du logiciel (éviter d’avoir un code qui fait la même chose à deux endroits différents). En cherchant à éviter la duplication et en suivant une série de bonnes pratiques, que nous vous détaillerons dans la suite de ce document, une architecture logicielle va progressivement se dessiner.

A ce point de l’article, je tiens à rappeler que cette pratique n’enlève en rien la nécessité d’avoir une phase d’architecture avant-projet (voir sur ce sujet l’article précédent). La différence se situant dans le fait que la phase d’architecture amont sera plus légère et définira une vision technique plutôt que le détail de la mise en œuvre. Un manque de rigueur dans les bonnes pratiques du design émergent, une équipe pas impliquée ou l’absence de vision technique seront des éléments pouvant conduire à la ruine de votre projet.

Bonnes pratiques de développement

Cette deuxième partie va s’intéresser aux “principes” permettant la mise en œuvre des architectures émergentes. Très fortement conseillés, ces éléments sont à garder en tête pendant la phase de développement. Ce sont les outils dont vont disposer les développeurs pour garantir la qualité de l’architecture.

Le point sur lequel est construit le principe des architecture émergente est la suppression des duplications, ce qui a donné naissance à l’acronyme DRY : Don’t Repeat Yourself (en français : ne te répète pas). C’est donc le premier point à respecter, systématiquement factoriser deux procédures similaires. Cependant cela doit se faire en respectant un ensemble d’autres bonnes pratiques listées dans la suite, permettant de garantir la bonne architecture du logiciel.

Vous devez faire très attention à respecter les principes d’une forte cohésion associée à un faible couplage. Le principe d’une forte cohésion signifie que vos modules doivent former un tout cohérent et spécialisé (un module de facturation ne doit pas gérer les utilisateurs). Le faible couplage indique la facilité avec laquelle un composant peut être remplacé par un autre ayant le même rôle (par exemple changer le système qui gère les paiements).

Votre code étant factorisé, il est amené à être réutilisé au sein de l’application, souvent par d’autres développeurs. C’est la raison pour laquelle une attention particulière doit être portée à la qualité et la consistance du nommage de vos API et de vos fonctions. Les termes doivent être explicites et spécifiques (MailSender plutôt que MailManager pour une classe d’envoi de mail). Et cohérent, c’est à dire prévisible : même sans avoir la documentation un développeur doit pouvoir deviner comment utiliser votre code source.

Les méthodes agiles ont un de leurs principes qui s’énonce ainsi :

Des logiciels opérationnels, plus qu’une documentation exhaustive

Cela n’a jamais voulu dire qu’il ne fallait pas documenter le code source, il faut simplement documenter ce qu’il faut mais pas plus. Un fichier expliquant simplement l’organisation de l’application en terme d’architecture sera d’une aide précieuse lorsqu’il faudra faire évoluer le logiciel. Pareillement, il ne sert à rien de commenter chaque ligne d’un code source, mais les parties complexes d’un logiciel se doivent d’être commentées pour en expliciter le fonctionnement.

Enfin, n’écrivez que du code dont vous allez effectivement vous servir. De la même façon qu’il ne sert à rien de sur-spécifier, l’écriture de code “au cas ou” (sur-développement) est inutile et peut être dangereux dans la maintenance du logiciel. Aussi limitez le code au strict nécessaire pour résoudre un problème donné. Il sera toujours possible de lui ajouter du fonctionnel manquant dans le futur. Dans le même esprit : supprimez tout code obsolète, ne laissez pas de code commenté. Dans tous les cas le code est sauvegardé par le logiciel de gestion des versions du code source, si vous en avez besoin dans le futur, vous pourrez le récupérer.

Méthodes de développement

Après avoir vu l’ensemble des principes qui servent de fondement aux designs émergents nous allons nous intéresser à la mise en pratique de ces concepts, soit par des méthodes permettant de vérifier qu’ils sont bien respectés, soit par des mises en œuvres pré-établies garantissant ces principes.

Tests unitaires, et pratique du TDD : Test Driven Developpement (Développement Dirigé par les Tests). Cette pratique est la plus importante de toutes dans les architectures émergentes. En effet les tests unitaires permettent de garantir qu’aucune régression n’apparaît lors des phases de refactoring. Le TDD veut que les tests soient écrits avant le code source, cela présente trois principaux avantages :

  • Vous ne pouvez pas oublier de tester un morceau du logiciel
  • Cela vous garantit de n’écrire que le code nécessaire : celui qui permet de passer les tests
  • Vous utilisez votre code avant même de l’avoir écrit, ainsi vous pouvez identifier des problèmes de conception avant même la création du code. Ce dernier point est nommé TFD : Test First Design (tester d’abord le design).

Après chaque ajout fonctionnel vous devez factoriser votre code, même après l’ajout d’une simple fonction vous devez vous poser la question de savoir si vous ne pouvez pas la factoriser avec du code existant.

Enfin, les Design Patterns vous seront d’une grande aide dans ce type de problématique. Ce sont des modèles de résolution de problèmes courants en ingénierie logicielle. Je vous conseille de bien connaître l’usage des principaux et réussir à identifier quand les mettre en œuvre. Attention par contre à ne pas sur-utiliser les design pattern, ce ne sont que des outils génériques et à ce titre ils ne peuvent pas répondre à toutes les problématiques.

Conclusion :

La pratique de l’architecture pendant la phase de développement demande une très grande rigueur dans sa mise en œuvre et un certain nombre d’outils à maîtriser. Malheureusement ces outils ne sont souvent pas enseignés dans les cursus d’informatique, et vous devrez faire attention à laisser un nombre suffisant de développeurs expérimentés dans chaque équipe de développement. La mise en place de coach inter-équipe peut aider à la mise en place de ces bonnes pratiques.

Pour conclure cette série d’articles sur l’architecture logicielle, nous terminerons avec la question de la réutilisation inter-projet de composants logiciels dans le cadre des architectures agiles.

Image issue de wikipedia

Publicités

3 réflexions sur “Concepts de l’architecture logicielle : le design émergent

  1. I feel like Im regularly seeking interesting features you just read about a number of subjects, but I handle to add in the blog among our translates every day when you dbddeedaebbf

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s