La plupart des développeurs néglige les aspects d’exploitation du logiciel qu’ils développent. Un programme est toujours écrit pour fonctionner en production – heureusement – et écrire du code permettant une bonne exploitation requiert quelques bonnes pratiques étayées par l’expérience.
Sans entrer dans des sujets avancés comme la programmation orientée “aspects”, nous pensons qu’il existe des dimensions de base de l’instrumentation du code que tout développeur logiciel devrait connaitre.
Traces et débogage
Le premier élément critique de l’instrumentation est la gestion des traces. Ajouter des traces à votre code est toujours une bonne idée. Cela peut parfois avoir un impact sur les performances mais cela se gère facilement en ajoutant différents niveaux de traçabilité, configurables au moment de l’exécution.
Trop de développeurs continuent à favoriser le débogage à la traçabilité faisant disparaitre leur investissement dès l’instant où ils referment leur déboguer. Bien utilisées, les traces sont un investissement plus durable et vous permettent de tirer parti de l’information pour comprendre et résoudre les problèmes en production. Souvent, les problèmes arrivent avec des combinaisons non-anticipées de chemins de code ou de données, de sorte que le développeur ne peut pas faire trop de raccourcis ou hypothèses en développant. Le débogage ne sera alors pas bien utile.
En outre au fil du temps, des développeurs différents peuvent contribuer à l’application, et les traces ajoutées au code sont conservées et préservent l’investissement de chaque contributeur.
La gestion des exceptions
Le traitement des exceptions est le deuxième point important de l’instrumentation du code. Quand une exception survient, il se peut que vous soyez dans un scénario imprévu, ou au minimum, dans des conditions spécifiques qui nécessitent de l’attention.
Traiter correctement les exceptions en prenant des actions pertinentes pour maintenir l’intégrité, pour fournir des informations sur les valeurs de données ou sur la manière de les obtenir peut être critique pour pouvoir effectuer le support de l’application en production.
Avec .NET, nous voyons beaucoup de mauvaises pratiques autour de la gestion des exceptions, comme celles-ci :
Le seul résultat de ce code est de perdre la trace de l’information. Ne rien faire serait effectivement mieux qu’intercepter l’exception et réduire l’information disponible. Si vous décidez de gérer une exception, assurez-vous de pouvoir ajouter de l’information et de la valeur au cas spécifique que vous interceptez.
Enfin, si vous souhaitez que la pile complète d’information soit disponible en production (avec la source et le numéro de ligne du fichier), c’est également une bonne idée de déployer les fichiers symboles (. PDB) notamment pour le déploiement d’application orientée serveur (web) ce qui n’est pas toujours fait.
Mesure de la performance
Dans Windows, il existe un moyen très simple de fournir de l’information utile sur la performance au moment de la production.
Les compteurs de performance sont directement intégrés dans le système d’exploitation (c’est en fait le cas depuis la toute première version de Windows NT) et vous pouvez créer vos propres compteurs pour surveiller les informations pertinentes avec tous les outils associés à Windows (Observateur d’événements). Du point de vue du développeur, les compteurs sont également faciles à définir ainsi que les classes associées.
De notre expérience, ces compteurs sont rarement utilisés par les développeurs d’application, dans la mesure où beaucoup ont tendance à ne considérer que les compteurs du système d’exploitation ‘prêt à l’emploi’ ou des composants de bas niveau, perdant ainsi l’opportunité de mesurer la performance dans des scénarios réels.
Investir dans ces compteurs est un moyen simple et pragmatique d’identifier les facteurs clés pour améliorer la performance au cours des différentes versions de votre application.
Il existe également des outils qui peuvent aider dans le “profiling” du code a posteriori mais c’est un processus en général plus lourd et dont les résultats sont plus aléatoires ou spécifiques.
La récupération des données et la journalisation
Enfin, pour aider les gens qui font le support de votre application en production à comprendre les problèmes ou optimiser les opérations, il est souvent pertinent de leur fournir des données relatives aux applications concernées.
Le développeur de l’application connait en général quand il code les données critiques qui doivent être disponibles pour l’analyse d’un problème en production.
Par conséquent, n’hésitez pas à placer ces données à un endroit pertinent pour votre application, que ce soit des fichiers journaux d’application ou une base de données spécifique, en fonction de votre architecture et des contraintes techniques.
En résumé, s’assurer que ces 4 dimensions sont couvertes n’est pas réellement compliqué. Cela relève plus de discipline que d’expertise.
A lire aussi
- Commenting, Testing, and Instrumenting Code from Dr Dobbs
- Instrumentation by Thomas Kyte
- An Introduction To Performance Counters by Michael Groeger
- Effective Code Instrumentation? discussion on Stack Overflow
