Une application vit : elle évolue dans le temps, s’agrémente de nouvelles fonctionnalités et/ou répond à des usages étendus.
Techniquement parlant, il convient alors de repartir du code source de la version 1 de l’application pour créer une version 2. Modifier un code source existant est toujours délicat : compréhension du code, risque de régressions etc… Il est donc préférable de réaliser un code applicatif de qualité pour faciliter sa maintenance et les évolutions à moyen-long terme.
Les régressions peuvent avoir bien des origines : un code peu lisible ou compréhensible, ou encore un impact dans une autre partie de l’application que l’on ne soupçonnait pas…
On appelle « dette technique », tous ces problèmes que l’on a laissé de côté, consciemment ou inconsciemment, pour y revenir « plus tard », « quand on aura le temps »… Une application contenant trop de dette technique devient trop difficilement maintenable, chaque évolution est un risque important pour sa stabilité. Il apparaît alors plus raisonnable de s’équiper de divers outils pour payer sa dette au fur et à mesure et éviter de se retrouver dans une situation ingérable.
Prenons pour exemple, un socle technique développé en PHP. Langage de programmation clé au sein du pôle APPS d’A5sys.
Harmonisation du code – phpCs et esLint
L’harmonisation du code consiste à mettre en place des règles imposant une utilisation particulière de la syntaxe des langages de programmation utilisés.
Faut-il, par exemple, faire un retour à la ligne entre le nom d’une fonction et l’accolade qui la suis ? Nous savons qu’il y a autant d’avis sur la question qu’il existe de développeurs…alors comment garder une cohérence lorsque nous travaillons à plusieurs sur un même projet ?
Harmoniser la syntaxe du code permet de contraindre les développeurs à utiliser la même syntaxe. Ainsi, lorsqu’un développeur est amené à reprendre le travail, il ne perd pas de temps à s’étonner des choix de syntaxe et peut ainsi être opérationnel plus rapidement sur le projet : on favorise la réversibilité.
Tests unitaires – phpUnit
Les tests unitaires sont des scripts vérifiant le bon fonctionnement d’une petite partie du code, d’une fonction précise ou encore d’une « unité » du code. Lancés régulièrement, ils permettent de « checker » que des travaux en cours ne viennent pas casser une partie qui fonctionne déjà correctement. Et font ainsi gagner un temps précieux sur les phases de qualification et de recette.
Validation du mapping Doctrine
Doctrine est une dépendance/librairie qui permet de modéliser/mapper en PHP la structure de la base de donnée. Un mapping erroné provoquera une erreur lorsque Doctrine tentera de récupérer les données en base de données. La librairie met à disposition une ligne de commande permettant de vérifier que le mapping a été correctement effectué.
Détections des dépendances/librairies non-utilisées
Au sein des projets, nous utilisons très souvent des librairies créées par des tiers et mis à disposition. Pour une raison quelconque, un développeur peut avoir embarqué une librairie qui finalement n’est pas utilisée. Il existe un outil qui permet s’assurer que le projet ne contient pas de dépendances inutilisées et donc inutiles.
Cet outil fonctionne sur n’importe quel projet PHP qui utilise Composer comme gestionnaire de dépendances.
Lien : https://github.com/Insolita/unused-scanner
Détection des failles de sécurités dans les dépendances utilisées
Utiliser les librairies développées par des tiers permet de gagner du temps et évite d’avoir à réinventer la roue. Ces libraires peuvent cependant embarquer des failles de sécurité… Il existe un référentiel sur Internet permettant de connaitre les failles références pour les différentes versions de dépendances.
Le référentiel indique à partir de quelle version de cette librairie la faille détectée a été corrigée. Il est ainsi possible de connaitre les dépendances à risque pour lesquelles il faut faire une mise à jour. Cet outil ne fonctionne qu’avec les projets réalisés avec le Framework Symfony.
Lien : https://github.com/sensiolabs/security-checker
Comment intégrer ces outils ?
Utilisés de manière occasionnelle, ces outils vous permettent seulement de constater par intermittence à quel point votre projet est en retard et quel sera le délai pour tout remettre en place : le projet a accumulé une dette technique.
Il apparait plus pertinent de vérifier régulièrement l’état du projet pour permettre des corrections au fil de l’eau.
1. Intégration dans les éditeurs de code
Les éditeurs de code tels que VsCode ou PhpStorm permettent d’intégrer ces outils, en particulier ceux vérifiant que la syntaxe du code correspond aux règles fixées.
2. Intégration continue avec Jenkis ou GitlabCi
Il est possible de mettre en place des contrôles plus ou moins fort dans les outils d’intégration continue afin de vérifier et contrôler le code présent dans le gestionnaire de source (ex : Git). Ces contrôles peuvent aller de la simple alerte email au blocage de la mise à jour du code dans Git.
* Avec Jenkis, il est possible de créer un job qui permet vérifier si une branche Git a été mise à jour, et si tel est le cas, lancer tous les contrôles
* Avec GitLabCi, il est en revanche possible de mettre des contrôles plus forts. Et de bloquer les fusions (merge) du code vers la branche git contenant la version principale du logiciel. Le développeur ayant introduit une erreur dans le code applicatif devra donc impérativement la corriger.
Quelle méthodologie adopter en fonction des projets ?
1. Sur un nouveau projet
Pour éviter d’accumuler de la dette technique sur un nouveau projet, il est important de prendre le temps au lancement du projet pour partir sur de bonnes bases. Cela passe par la mise en place de ces différents contrôles qui permettront de garantir que le projet n’aura pas d’erreurs (ou le moins possible).
2. Sur un projet existant
Lorsqu’un projet existe depuis plusieurs mois voire plusieurs années, beaucoup de dette technique ont pu s’accumuler. Appliquer immédiatement ces règles en mode « bloquant » n’est pas envisageable car cela empêcherait l’équipe projet de produire du code tant que toutes les erreurs ne seront pas corrigées…
L’idéal est donc de procéder ainsi :
* Effectuer un audit de l’ensemble de la dette technique accumulée, et chiffrer le temps nécessaire pour la corriger.
* Corriger entièrement un type d’erreur puis appliquer la règle associée de manière automatique.
Simon Landais – Concepteur Développeur chez A5sys
