Reprendre un projet .NET pour le moderniser

Que ce soit votre propre projet que vous souhaitez remettre au goût du jour, ou bien un projet d’un autre programmeur ou d’une autre équipe dont vous prenez la relève pour la maintenance, vous souhaitez sans doute profiter des dernières avancées techniques en les intégrant dans votre projet, tout en ne compromettant pas sa stabilité.

Gestion des sources

Assumons en partant que votre code est conservé sur un gestionnaire de source, qui vous permet de garder les différentes versions de votre code. Il en existe plusieurs sur le marché, gratuits et payants. Ils offrent tous les mêmes fonctionnalités de base, donc nul besoin de les comparer pour le but que nous nous sommes fixés ici. Si différence il y a, c’est surtout dans les outils connexes à la gestion de source, notamment la gestion du travail d’équipe, ainsi que l’intégration d’outils d’intégration continue.

Vous pourrez également expérimenter les différentes techniques proposées, en parallèle du travail urgent à effectuer grâce à une ou des branches de développement, fonctionnalité que proposent la plupart des gestionnaires de sources. Ainsi vous pourrez tester la viabilité d’un changement, sans gêner l’avancement du projet. Les techniques proposées sont également un bon moyen d’en apprendre plus sur le code. À défaut d’appliquer ces changements immédiatement en production, elles peuvent vous aider à vous familiariser avec le code dans son ensemble sans passer par des demandes de corrections ou d’ajout.

Est-ce utilisé ?

Une des premières étapes est d’évaluer quel code est encore utilisé. Au fur et à mesure de la durée de vie d’un projet, il arrive que certaines parties du code ne soient plus utilisées. Soit parce que le UI associé n’est plus accessible, soit parce que le fonctionnement a changé, et que la partie de code en question n’est plus utilisée. Mais comment faire pour détecter ce code mort ? Différentes techniques sont possibles, et peuvent être utilisées suivant le type et la structure de votre projet.

Pour un projet monolithique, et dont la compilation résulte en un assembly exécuté par l’utilisateur (par exemple une application WinForms, ou WPF), il est possible de rendre privées la plupart des classes. Attention tout de même à certains types de sérialisation, et à la réflexion dont le fonctionnement peut être influencé par la visibilité des classes. Une fois la visibilité des classes réduites, vous pouvez utiliser l’analyse statique de code fournie par Visual Studio pour détecter les parties de code qui ne sont pas utilisées. Une fois ce code inutile supprimé, vous éviterez ainsi d’appliquer les prochaines techniques et de passer du temps sur du code qui n’est plus utilisé.

Avertissements du compilateur et des outils d’analyse statique de code

Pour cette étape, assurez-vous que le niveau d’avertissement maximal est activé. Vérifiez également que si certains avertissements sont ignorés, la documentation est présente pour expliquer pourquoi, et s’ils sont ignorés seulement là où c’est justifié de le faire. Le compilateur .NET donne certains indices de problématiques de code. En plus de ces avertissements de base, vous pouvez utiliser des outils d’analyse statique. Visual Studio en possède un de base, mais depuis l’introduction de Roslyn, une grande quantité d’analyseurs sont disponibles sous différents formats (extensions Visual studio, packages NuGet), et permettent de détecter des parties de code problématiques.

Certaines extensions se spécialisent dans les bonnes pratiques de certains modules bien spécifiques comme l’asynchronisme, d’autres sont plus généraux. À vous d’expérimenter ceux qui vous conviennent le mieux, la plupart permettant également d’activer ou de désactiver certaines règles.

Préférez également des extensions qui fournissent des exemples de correctifs, afin d’être guidé. Certains avertissements peuvent nécessiter des changements importants dans la structure du code, surtout ceux reliés à la notion de Disposable. Il est parfois préférable d’attendre d’avoir introduit des tests d’intégration et des tests unitaires avant d’opérer ces changements. Cependant d’autres avertissements peuvent être réglés avec plus d’assurance, dépendamment de votre expérience.  Les avertissements amenant une possible amélioration des performances sont les plus intéressants à régler, car ils donnent une visibilité au travail d’amélioration effectué.

Test unitaires et tests d’intégration

Certains avertissements ne pourront pas être réglés sans des changements de code plus larges et plus complexes. Dans ce cas, mieux vaut mettre en place des tests avant d’effectuer les changements. Ces tests peuvent prendre plusieurs formes. Dans le cas de calculs, il peut être intéressant d’avoir des tests unitaires qui valident que pour certaines entrées, on a bien le résultat attendu. Ces tests couvrent une unité de code bien définie. D’autres tests vont nécessiter la mise en œuvre de plusieurs parties du logiciel, on parle dans ce cas de tests d’intégration.

Les tests vont vous donner une assurance lors des changements apportés au code, et vous éviteront d’avoir à tester manuellement votre application. Une étape de tests manuels peut être nécessaire pour découvrir les tests à effectuer, et vous devez également consulter vos utilisateurs finaux, pour vous assurer de tester les cas d’utilisation les plus fréquents. Une fois les cas d’utilisation déterminés, il faut au maximum automatiser ces tests pour les exécuter le plus fréquemment possible, et de fait les documenter.

Compartimentation du code

Une fois ces étapes effectuées, vous devriez avoir acquis une meilleure connaissance de votre code. Vous allez peut-être réaliser que pour faciliter vos tests, vous allez devoir revoir la façon dont est organisé votre code. En effet, peut-être que certains traitements qui doivent être testés ne peuvent pas fonctionner sans une dépendance qui ne peut pas être automatisée (du matériel informatique spécifique, ou un service web par exemple). Vous devrez donc compartimenter ces dépendances afin de pouvoir les simuler au moment des tests.

Conversion du code VB.NET

Ce point est un peu plus polémique, mais le langage VB.NET a avant tout été pensé comme un langage de transition entre la plateforme VB6 et la plateforme .NET. Les formations et les certifications Microsoft ne sont quasiment plus fournies qu’en C#, ainsi que la quasi-totalité des projets open-source .NET. Il peut donc être intéressant pour faciliter l’intégration de nouveaux programmeurs de convertir le projet de VB.NET vers C#. C’est cependant une étape délicate qui créera une certaine coupure dans l’historique du code, donc à vous de décider du meilleur moment, et si cette conversion doit vraiment avoir lieu.

Objectifs

Dans un premier temps, fixez-vous comme objectif d’explorer ces différents points dans un temps limite, et de ne pas forcément conserver le résultat. Vous apprendrez ainsi quels sont les changements qui semblent le plus payant, et ceux qui peuvent attendre. Vous en apprendrez également beaucoup sur votre code, et cela vous amènera à vous questionner sur sa structure générale.

À ce moment, vous devrez rechercher les ressources qui vous permettront de tendre vers une architecture logicielle plus solide si le besoin s’en fait sentir, afin d’orienter au mieux vos prochains changements, que ce soit des correctifs, ou l’ajout de fonctionnalité.

Auteur: Mathieu Penant est analyste-programmeur au sein de l'entreprise SEIKA logiciel. Cette entreprise est spécialisée dans le développement de solutions logicielles conçues sur mesure.