Nous avons déjà détaillé 3 actions à mener pour anticiper la qualité logicielle dans un article précédent. Voici 2 autres actions et pas des moindres.

 

Documenter l’architecture du code

Documenter l’architecture du code c’est fournir le mode d’emploi pour comprendre le découpage de l’architecture, les principaux composants, leurs sous-composants, et leur orchestration, qui appelle qui, … cette documentation doit expliquer les concepts-clés du code, schématiser les composants et leurs dépendances, décrire les commandes pour jouer les tests, …

schéma exemple architecture de code

Ecrire de la documentation, tout comme écrire des tests, doit faire partie intégrante du quotidien d’un développeur.

Un code avec une documentation à jour sera plus facile à maintenir. Il constitue un outil de communication efficace pour les équipes et un gain de temps considérable pour comprendre le code.

Le point de départ peut s’avérer être le rassemblement des éléments suivants

  • Les documents liés aux méthodes agiles : compte-rendu de rétrospectives, axes d’amélioration, correspondance sprint/version/fonctionnalités …
  • La définition des termes métiers et les règles associées: le domaine métier est parfois plus complexe à appréhender que le code lui-même, surtout pour un débutant.
  • Un plan d’architecture matérielle et système : serveurs ou composants Cloud, configurations logicielles, plateformes (dev/test/pré-production).
  • L’architecture et la structure du code : surtout si le framework est maison et basé sur une architecture particulière, il est intéressant de définir le chemin d’exécution : point d’entrée, exemple de cheminement des informations, couches chargées de la validation des données, de la persistance, de la sécurité etc
  • Modèle de données de la base de données : avec par exemple les valeurs possibles pour les colonnes. On peut aussi lister les règles qui existent entre deux colonnes (valeur d’une colonne qui dépend de la valeur d’une autre colonne). Certains outils facilitent la création de cette documentation (tables, colonnes, contraintes, description des objets) en se basant sur des annotations des objets.
  • Procédures et check-lists : étapes à suivre lors du déploiement, de la création de branches, de la modification de code spécifique, des code-review et check-list des bonnes pratiques concernant la sécurité par exemple.
  • Change-log des versions : utile pour repérer rapidement les changements majeurs et fonctionnalités de chaque version.
  • Roadmap : pour donner la vision avec les dates importantes (mises à jour, déploiements, réunions …). Il peut s’agir d’un planning partagé avec les équipes.

Mais aussi

  • Jeux de tests : quel utilisateur possède quel droit et quelle configuration sur quelle plateforme ?
  • Documentations externes des outils : lien vers les tutoriels d’initiation aux outils (Git, Frameworks…)
  • Boite à idées : ou application web de mind-mapping pour envisager toutes les solutions aux problèmes rencontrés et pouvoir en débattre en sprint.

Plus la documentation est structurée et tenue à jour, plus elle sera un véritable atout pour mener à bien un projet sans dérapage majeur.

Déployer une intégration continue

Mener un projet sans intégration continue, c’est un peu comme creuser un trou sans pelle. L‘intégration continue, c’est surtout l’automatisation de toute la chaîne de construction d’un logiciel

L’objectif de cette approche moderne est de progresser par étapes afin de concevoir le processus de développement plus efficacement et de pouvoir réagir aux modifications avec flexibilité.

Les développeurs intègrent leur code terminé une ou plusieurs fois par jour dans le sytème de gestion des sources, et en quelques minutes, le code source est accessible à tous. Si l’on découvre une erreur de « compilation » , de construction d’un composant du logiciel ou de certains tests automatisés, elle peut alors être immédiatement localisée et corrigée rapidement.

 

Finalement, l’intégration continue permet surtout de :

  • Avoir un processus automatique bien défini pour diminuer le risque d’erreurs « humaines » liées à une construction manuelle du logiciel.
  • Diminuer le risque de régressions et de recevoir une notification, si vos tests ne passent plus suite au dernier incrément de code.
  • Générer des mesures sur la qualité de votre code pour piloter la qualité de vos projets.
A lire sur le même sujet : Automatiser ses développements

Vous l’avez certainement compris, bâtir une stratégie efficace de gestion de la qualité logicielle nécessite un terreau fertile. L’aspect humain est primordial tout comme la collaboration et la mise en place des bonnes pratiques et des méthodologies de conception et de développement.