Travailler avec le code hérité et 3 étapes pour le mettre à jour

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.

Qu'est-ce que l'ancien code?

De nombreuses personnes utilisent le terme «code hérité» pour désigner simplement l'ancien code. Mais «ancien» et «héritage» signifient des choses différentes pour différentes personnes. Ici, j'utilise la définition du code hérité comme tout code existant qui n'est plus pris en charge ou mis à jour et que l'équipe a une connaissance limitée à ce sujet.

La connaissance du code peut être incomplète pour plusieurs raisons, telles que:

• L'équipe a acquis un projet d'une autre partie de l'organisation.
• L'auteur original a quitté l'équipe et a pris connaissance du code avec lui.
• La fonctionnalité fournie par le code n'est plus une priorité commerciale et est restée inchangée, ce qui entraîne des détails oubliés sur le code.

Dans tous les cas, soyons clairs: le code hérité est la règle, pas l'exception. Une grande partie de l'infrastructure logicielle dans le monde fonctionne aujourd'hui sur du code hérité. La question est alors de savoir comment atténuer les risques associés au code hérité lorsque nous devons apporter un changement? Dans cet article de blog, je vais vous donner quelques solutions pour travailler efficacement avec le code hérité.

Le code hérité est un obstacle à l'agilité et au DevOps

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.

Atténuer la dette technique

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.

Qu'est-ce que la dette technique ?

Dette technique est le coût de l'atténuation du risque associé à la mise en œuvre d'une solution imparfaite pour atteindre votre objectif de délai de mise sur le marché ou de coût de développement. Par exemple, renoncer aux mises à niveau d'une bibliothèque parce que cela aurait retardé la sortie représente une dette technique sous la forme du temps qu'il faudra 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.

Faut-il s'inquiéter de la dette technique ?

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.

Augmentation de la couverture sur le code hérité

Lorsque les organisations héritent d’une base de code héritée, elles adoptent souvent une politique de couverture qui les aide à créer une base de référence pour de nouveaux développements. Le code existant est déjà sur le terrain et est censé fonctionner, l'accent est donc mis sur la garantie de la qualité du nouveau code. Pour se conformer à la politique de couverture, de nombreuses organisations augmentent la couverture du code existant via le création de nombreux nouveaux tests unitaires. Une faible couverture fait baisser les mesures globales, ce qui rend difficile la mesure précise de la couverture de votre nouveau développement. Si vous savez que vous travaillez avec du code existant qui est bien couvert, les mesures globales du projet peuvent indiquer si le nouveau développement évolue 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.

Créez des tests Java significatifs et maintenables

Utilisez un outil qui vous aide à créer rapidement des tests significatifs pour couvrir votre ancien code Java. Jtest Parasoft fournit une interface pointer-cliquer qui offre aux développeurs un processus de création automatique de tests basé sur le code existant. La suite de régression résultante est significative, maintenable et extensible. Les clients déclarent économiser plus de 50 % de leurs efforts de développement pour créer des tests pour leur code existant.

Les 3 étapes pour mettre à jour votre ancien code

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.

1. Définissez votre portée

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.

• Combien de violations d'analyse statique avez-vous et quelle est leur gravité? Vous devez comprendre combien de défauts potentiels sont intégrés au code.
• Quelle est votre couverture de test actuelle? Une faible couverture représente un risque potentiel associé au changement.
• Combien de nettoyage sera nécessaire? Des mesures supplémentaires, telles que la complexité, les commentaires, etc. peuvent fournir une perspective sur l'état de la qualité du logiciel.

Parasoft fournit une puissante plate-forme d'analyse pour capturer, corréler et rapports violations de l'analyse du code, résultats des tests, analyse de la couverture et autres données sur la qualité des logiciels. La plateforme va au-delà des rapports statiques. Il applique également une analyse supplémentaire pour vous aider à identifier les parties de l'application affectées par le changement.

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.

2. Capturer le comportement

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 avec des tests significatifs. Jtest peut créer des tests unitaires juste pour les parties non couvertes du code, évitant ainsi les tests redondants pour le code qui comporte déjà des tests unitaires.

Parasoft Jtest peut également être intégré aux fournisseurs OpenAI ou Azure OpenAI, ce qui permet aux développeurs d'augmenter davantage leurs tests grâce à la saisie d'invites en langage naturel conçues par l'utilisateur qui décrivent comment les cas de test doivent être refactorisés. Cela offre des options de personnalisation flexibles aux développeurs souhaitant modifier rapidement cas de test de manière spécifique en fonction des exigences 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.

3. Améliorer le code hérité isolé

Une fois le comportement du système capturé, vous pouvez commencer à corriger les violations, à traiter les PR ou à appliquer les modifications sur lesquelles vous souhaitez vous concentrer avec un risque minimal de rupture des fonctionnalités existantes. Parasoft peut vous aider gérer la dette technique existante et placez les données, telles que les violations d'analyse statique, dans des flux de travail appropriés où elles peuvent être facilement redéfinies, supprimées ou résolues pour améliorer la qualité globale de l'application. Les modifications d'une version à l'autre doivent également être surveillées dans le cadre du processus continu, afin de garantir que la qualité du logiciel ne se détériore pas.

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.

Assurer la couverture sur le code modifié

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.

En conclusion : travailler avec du code hérité

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.