Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Blog Parasoft
Travailler avec du code existant est une réalité quotidienne. Cependant, les lacunes dans la connaissance du code représentent des risques potentiels. Lisez la suite pour comprendre comment atténuer ces risques et mettre à jour votre code existant.
Aller à la section
Lorsque vous traitez avec du code hérité, vous avez besoin d'un moyen durable de gérer le changement. Travailler avec du code hérité peut être un obstacle à Agile et DevOps, mais vous pouvez relever le défi en tirant parti des technologies appropriées.
Beaucoup utilisent le terme « code hérité » pour désigner simplement un code ancien. Cependant, les termes « ancien » et « hérité » peuvent avoir des significations différentes selon les personnes. Ici, j'entends par code hérité tout code existant qui n'est plus maintenu ni mis à jour, et dont l'équipe a une connaissance limitée.
La connaissance du code peut être incomplète pour plusieurs raisons, telles que:
Quoi qu'il en soit, soyons clairs : le code hérité est la règle, et non l'exception . Une grande partie de l'infrastructure logicielle mondiale actuelle repose sur du code hérité. Dès lors, comment atténuer les risques liés à ce code hérité lorsqu'une modification s'avère nécessaire ? Dans cet article, je vous proposerai des solutions pour travailler efficacement avec du code hérité.
Le problème avec le code existant n'est pas son âge, c'est que vous ne comprenez pas comment sa modification peut affecter les fonctionnalités existantes. Les lacunes dans les connaissances associées au code existant peuvent devenir un obstacle si vous passez à une nouvelle méthodologie de développement, telle qu'Agile ou DevOps.
Agile et DevOps sont devenus les méthodologies dominantes pour la création de logiciels, car ils aident les équipes à itérer et à publier rapidement des applications dès que les fonctionnalités commercialisables minimales sont prêtes. Des cycles de développement courts et fréquents sont la marque des méthodologies de développement itératives, mais ces approches ne laissent souvent pas de place pour atténuer les résultats potentiellement problématiques lorsque vous utilisez du code existant. Essayer de parcourir rapidement du code que vous ne comprenez pas est susceptible d'introduire de nouveaux problèmes.
Suivre les modifications du code source est beaucoup plus facile lors du démarrage de nouveaux projets. Pour les projets qui existent depuis un certain temps, les équipes travaillent généralement avec des systèmes qui impliquent du code existant. Les développeurs ne savent peut-être pas comment fonctionne la base de code existante, mais doivent néanmoins corriger les défauts ou étendre les fonctionnalités sans introduire de nouveaux problèmes. Et même des changements superficiels ou apparemment mineurs peuvent avoir un impact significatif sur l’application.
Le jeu du développement logiciel consiste à constamment équilibrer la qualité des logiciels, les délais de mise sur le marché et le coût de développement. Dans la plupart des cas, nous faisons des compromis pour atteindre nos objectifs commerciaux en fonction de l'évolution du marché. Au fil du temps, nous accumulons des dettes techniques.
La dette technique représente le coût lié à la gestion des risques associés à la mise en œuvre d'une solution imparfaite pour atteindre un objectif de délai de commercialisation ou de coût de développement. Par exemple, renoncer aux mises à jour d'une bibliothèque sous prétexte que cela aurait retardé la publication constitue une dette technique, correspondant au temps nécessaire pour mettre à jour la bibliothèque ultérieurement.
Dans de nombreux cas, les bases de code héritées sont lourdes de dettes techniques sous la forme d'une faible testabilité, d'une faible couverture, d'un code trop complexe, etc. La dette technique peut freiner l'application de nouvelles pratiques de développement logiciel, car les équipes sont constamment confrontées à la question de savoir s'il faut ou non s'attaquer à la dette.
Pour mettre les choses en perspective, chaque application a une dette technique, et de nombreuses organisations peuvent investir des ressources importantes pour la rembourser sans en tirer des avantages substantiels. En fin de compte, la décision d’investir des ressources dans le remboursement de la dette technique dépend des parties de votre application que vous envisagez de modifier. Mais vous ne le saurez que si vous prenez des mesures supplémentaires. J'y reviendrai dans un moment.
Lorsqu'une organisation doit gérer un code source existant, elle adopte souvent une politique de couverture de code afin d'établir une base de référence pour les nouveaux développements. Le code existant étant déjà en production et censément fonctionnel, l'objectif principal est de garantir la qualité du nouveau code. Pour se conformer à cette politique, de nombreuses organisations augmentent la couverture du code existant en créant de nombreux tests unitaires . Une faible couverture pénalise les indicateurs globaux, ce qui complique la mesure précise de la couverture des nouveaux développements. En revanche, si le code existant est bien couvert, les indicateurs globaux du projet permettent de vérifier que les nouveaux développements progressent dans la bonne direction.
La justification sous-jacente de cette stratégie est solide, mais le problème est que les organisations n'ont généralement pas le temps de créer des tests unitaires de bonne qualité pour combler ces lacunes. Il devrait y avoir une meilleure façon de gérer le code existant.
Utilisez un outil qui vous aide à créer rapidement des tests pertinents pour votre code Java existant. Parasoft Jtest offre une interface intuitive qui permet aux développeurs de créer automatiquement des tests à partir du code existant. La suite de tests de régression ainsi générée est pertinente, maintenable et extensible. Nos clients constatent une réduction de plus de 50 % de leurs efforts de développement pour la création de tests pour leur code existant.
Plutôt que d'essayer de travailler au niveau macro, créez une base de référence et restreignez la portée de vos activités de qualité aux zones de code affectées par vos modifications planifiées. Après avoir pris des mesures pour évaluer la portée et l'état du code, vous devez créer des tests qui capturent le comportement actuel afin que l'équipe puisse comprendre comment les modifications peuvent affecter les fonctionnalités existantes.
Vous pouvez ensuite tirer parti d'une gamme de technologies qui vous aident à collecter des analyses lorsque vous refactorisez le code hérité et vous assurez que votre investissement dans les changements de code améliore la sûreté, la sécurité et la fiabilité des systèmes hérités.
Comprendre comment les changements affectent le comportement du système nécessite au moins un point de données. Commencez par choisir une version de référence et commencez à suivre les métriques à l’avenir. Définissez votre portée et examinez trois caractéristiques du code existant.
Parasoft propose une plateforme d'analyse performante pour la capture, la corrélation et la génération de rapports sur les violations d'analyse de code, les résultats de tests, l'analyse de couverture et d'autres données relatives à la qualité logicielle. Cette plateforme va au-delà de la simple génération de rapports statiques. Elle effectue également des analyses complémentaires pour vous aider à identifier les parties de l'application affectées par les modifications.
Vous pouvez identifier un ensemble spécifique de fichiers ou de répertoires et couvrir la portée, les violations d'analyse statique et les données de métriques pour ces ressources spécifiques. Ces informations vous aident à créer une référence pour les zones de la base de code avant d'apporter des modifications à ces parties du code.
Armé d'un point de données initial, l'étape suivante consiste à commencer à capturer le comportement actuel du système en créant des tests. La création d'une suite de régression de haute qualité capture le comportement existant, créant ainsi un filet de sécurité pour garantir que les modifications n'interrompent pas les fonctionnalités.
Parasoft Jtest est parfaitement adapté à cette tâche car il vous permet de créer une base de référence de tests JUnit en masse, y compris des assertions, basées sur le code existant. Jtest inclut également la possibilité de créer des tests qui accèdent directement aux méthodes privées lorsque le code existant n'a pas été écrit à l'origine dans un souci de testabilité.
Il est préférable d'étendre la couverture de test avec des tests pertinents. Jtest peut créer des tests unitaires uniquement pour les parties du code non couvertes, évitant ainsi les tests redondants pour le code déjà testé.
Parasoft Jtest peut également être intégré aux fournisseurs OpenAI ou Azure OpenAI, permettant ainsi aux développeurs d'enrichir leurs tests grâce à des instructions en langage naturel personnalisées. Ces instructions décrivent comment les cas de test doivent être remaniés. Cette intégration offre des options de personnalisation flexibles aux développeurs souhaitant adapter rapidement les cas de test aux besoins spécifiques de leur organisation.
Vous devez vous efforcer d’obtenir le niveau de couverture le plus élevé possible, mais dans la plupart des cas, atteindre une couverture de 100 % sur l’ensemble de la base de code n’est pas pratique. Continuez à lire pour découvrir une technique supplémentaire que vous pouvez appliquer comme filet de sécurité pour garantir la couverture du code modifié.
Lorsque vous avez une bonne couverture d'un point de vue fonctionnel, vous pouvez commencer à apporter des modifications et à modifier les tests au fur et à mesure.
Grâce à l'analyse du comportement du système, vous pouvez corriger les anomalies, traiter les demandes de fusion ou appliquer les modifications prioritaires en minimisant les risques d'impact sur les fonctionnalités existantes. Parasoft vous aide à gérer la dette technique et à intégrer les données, comme les anomalies d'analyse statique, dans des flux de travail adaptés. Ces données peuvent ainsi être facilement repriorisées, ignorées ou résolues afin d'améliorer la qualité globale de l'application. Il est également important de surveiller les modifications d'une version à l'autre dans le cadre de ce processus continu, afin de garantir le maintien de la qualité du logiciel.
Le meilleur moment pour résoudre la dette technique dans le code hérité est lorsque vous apportez des modifications. Les données déclarées doivent être incluses dans les informations statistiques globales sur le projet. La dette technique peut ne pas avoir d'impact immédiat sur l'application, mais vous devez appliquer les meilleures pratiques pour la contenir et la gérer systématiquement. La refactorisation du code hérité chaque fois que vous devez apporter des modifications vous aide à réduire progressivement la dette.
Le processus dont nous avons discuté garantit que la portée des modifications n'a pas d'impact négatif sur les fonctionnalités existantes, mais vous devez également vous assurer que l'équipe suit les bonnes pratiques à l'avenir. Continuer à maintenir un niveau élevé de couverture et rédiger ou mettre à jour des tests à mesure que le code évolue nécessite une adhésion au niveau culturel. C'est pourquoi Parasoft a développé une technologie qui vous avertit automatiquement lorsque le code modifié (nouveau ou modifié) ne respecte pas la politique de couverture.
En analysant les modifications entre les versions de base spécifiées, vous pouvez vous concentrer et surveiller les modifications dans l'ensemble de la base de code pour vous assurer que rien ne passe entre les mailles du filet. Atteindre une couverture à 100 % sur l'ensemble de la base de code n'est peut-être pas pratique, mais en surveillant la couverture du code modifié, l'équipe peut se concentrer sur les parties du code sur lesquelles on travaille activement et être sûre que toutes les modifications sont testées.
Les logiciels du monde entier fonctionnent sur du code transmis d'équipe en équipe. Gérer le code existant est une réalité quotidienne. Les lacunes dans les connaissances sur le code représentent des risques potentiels lorsque les développeurs apportent des modifications pour maintenir ou étendre les fonctionnalités, et les processus et technologies décrits ici devraient vous aider à acquérir la confiance nécessaire pour prendre en charge à peu près n'importe quelle base de code imposée à vos équipes.
