Architecture logicielle et sociale

Combien de fois par jour répétez-vous les mêmes actions? Copier des fichiers, vous authentifier chaque fois que vous compilez, effacer des fichiers temporaires, copier-coller des valeurs… probablement plus souvent que vous ne le croyez. Plus souvent on recommence une même activité, plus elle devient naturelle, automatique, et moins on se rend compte du temps qu’on passe à la faire. Résultat, votre temps “productif” est réduit, au profit d’actions démotivantes et répétitives. De plus, votre concentration est constamment compromise. Il existe pourtant un grand nombre d’outils prévus pour accélérer votre travail, prêts à être utilisés. Surtout, vous êtes en mesure de créer vos propres outils, plus adaptés que tout ce que vous pourriez trouver ailleurs. C’est une tâche plaisante et motivante qui optimisera votre temps, minimisera les perturbations et réduira les risques d’erreurs.

Les Batch Files

Dernièrement, je développais une application distribuée, qui consistait de deux services Windows. L’un lisait un dossier, et envoyait des données à l’autre qui produisait un artefact dans un autre dossier. Après chaque compilation, je devais donc aller dans un dossier, exécuter le premier service, répéter cette action pour le deuxième, prendre un fichier de test, le déposer dans le premier dossier, et vérifier le résultat dans le deuxième dossier. Finalement, je devais aller dans le gestionnaire de tâches, trouver les deux services et les arrêter. Cela impliquait plusieurs changements de dossiers, et plusieurs changements de fenêtres. J’estime le temps perdu à environ une trentaine de secondes par compilation, excluant la perte de concentration et les erreurs.

La première itération m’a prise environ vingt secondes. J’ai créé deux batch files, StartServices.bat et StopServices.bat. Ceux-ci contenaient simplement les deux lignes de commande nécéssaires à l’exécution et l’arrêt des services, soit:

StartServices.bat
c:\…\MonApplication\bin\Debug\MonApplication.exe

StopServices.bat
taskkill MonApplication.exe

Et c’était bien. J’avais économisé en moyenne une douzaine de clics, mais il manquait encore la touche finale. Celle qui me permettrait d’exécuter et d’arrêter ces services en un seul clic. J’ai donc simplement glissé mes batch files dans la barre de lancement rapide, et je leur ai assigné les icônes “Jouer” et “Arrêter”, issus des icônes de base de Microsoft Windows XP.

Temps utilisé: trente secondes.
Temps économisé: trente secondes par compilation.
Gains: Un nombre minimal d’étapes entre la compilation et l’essai, plus la satisfaction d’appuyer sur un petit bouton “Jouer” pour exécuter l’application.

Pour plus d’informations sur l’utilisation des Batch Files, voyez l’article Using batch files sur le site de Microsoft Windows.

N’oubliez pas non plus que Microsoft Visual Studio .NET supporte l’exécution de batch files avant et après la compilation. Si, par exemple, vous voulez effacer des fichiers temporaires après chaque compilation, c’est l’endroit par excellence. Voyez l’article How to: Specify Build Events (C#, J#) sur MSDN pour plus de détails.

Les macros

Il y a un ou deux ans, je travaillais sur un grand projet, où une demi-douzaine de développeurs travaillaient activement sur le code. Les commentaires //TODO s’accumulaient de manière impressionnante, et rapidement, plusieurs d’entre eux devenaient désuets. Certaines de ces tâches étaient importantes et abandonnées, d’autres, de simples remarques sur une approche “qui aurait pu être mieux”. Un de mes amis et partenaire développeur, Stéphane Lévesque, dans sa légendaire débrouillardise, a décidé que c’en était assez. Il s’est donc assis, et a réfléchi. Quelles informations ont de la valeur dans une tâche? Et comment faciliter le suivi de celles-ci? S’ensuivit une demie-journée de travail pour élaborer sa solution. Voici en quoi elle consistait.

Plutôt que d’avoir à taper “//TODO:” dans le code, il a assigné les touches “CTRL+/+/” à une macro. Cette macro demandait premièrement à l’utilisateur d’entrer un code, fait d’une lettre représentant le type de tâche, et d’un chiffre pour la priorité. La macro créait ensuite une ligne comme celle-ci:

//TODO:[P2] <curseur ici> (utilisateur, date)

Dans cet exemple, on peut lire “Tâche reliée à la perforance, de priorité moyenne, entrée par un tel utilisateur, à telle date”. En soi, cette macro, qui prenait moins de temps à entrer que de simplement taper //TODO:, réglait la majorité des problèmes que nous avions. Mais pour lui, ce n’était pas assez.

Il a donc pris une autre demie-journée pour créer une petite application qui lisait tous les dossiers de l’application, trouvait les fichiers .cs, et extrayait ces commentaires pour les exporter dans un Excel bien rangé.

Certaines macros prennent beaucoup moins de temps à développer. Que ça soit un formulaire que vous devez remplir pour accéder à la page que vous voulez déboguer ou un chemin à suivre à chaque fois, ou simplement un texte que vous devez retaper à chaque fois, les macros vous feront économiser un temps fou, tout en vous donnant l’opportunité de vous concentrer sur votre travail.

Pour plus d’informations sur les macros dans Microsoft Visual Studio, voyez l’article Visual Studio Macros sur MSDN. Vous trouverez aussi beaucoup d’outils sur internet, dont certains gratuits.

L’intégration d’outils à même le code

L’exemple le plus flagrant qui me vient à l’esprit est l’authentification. Combien de fois devez-vous vous ré-authentifier dans votre application? La solution simple et flexible est de créer, dans le web.config par exemple si vous utilisez ASP.NET, une clé contenant le nom d’utilisateur avec lequel vous voulez travailler. Dans votre code, vous n’aurez donc qu’à utiliser ce nom pour connecter automatiquement l’application. Pour une coche supplémentaire de sécurité, cerclez le code d’authentification automatique d’un #if(DEBUG) et #endif, pour éviter tout risque en production.

Ces outils peuvent aussi être plus subtils, par exemple, si vous développer un panier d’achats, l’intégration d’un bouton “Utiliser carte de crédit de développement”, qui utiliserait automatiquement l’addresse et les informations de carte de crédit de déboguage.

Attention! Ces outils doivent être très bien encapsulés, pour ne jamais affecter la version de production. Vous pouvez vous en assurer en ajouter au dessus des méthodes de débugage l’attribut:

[Conditional(”Debug”)]

Si vous devez adapter du code pour pouvoir interagir avec, peut-être est-ce une opportunité de rendre cette partie de l’application plus flexible et apte à être testée. Je vous conseille fortement d’utiliser des techniques de refactoring.

Vous trouverez plus d’informations sur le code conditionnel dans l’article Conditional Methods Tutorial de MSDN.

Des outils existants

Quoique je sois convaincu que de toujours s’appliquer à minimiser la redondance et maximiser la librairie d’outils propres à notre approche personnelle de développement est une pratique qui porte ses fruits, beaucoup de tâches sont si répandues que d’autres développeurs ont pris le temps de solidifer leurs outils et de les rendre disponibles sur internet. Des sites comme Code Project et GotDotNet contiennent un nombre impressionnant de ceux-ci. D’autres projets de plus grande envergure proposent des outils plus complets pour des ensembles de tâches, comme le déploiement avec NAnt, les tests avec NUnit etc. Ces outils s’adaptent souvent pour être complémentaires et vous permettre de vous concentrer sur ce qui ajoute de la valeur à votre développement.

Conclusion

Un peu comme le Test Driven Development, se fabriquer des outils et les maintenir est une philosophie qui demande de la discipline et du discernement. Dans un monde où les pressions sont constantes, il est difficile de prendre du recul et d’évaluer sa propre performance. Selon mon expérience, ça en vaut la peine. Je vous suggère de commencer par de petits changements, d’évaluer objectivement et subjectivement l’effet sur vous et votre travail. Peut-être aurez-vous vous aussi la piqure, et profiterez de chaque tâche répétitive comme d’une opportunité pour apprendre, optimiser votre développement et vous faciliter la vie!

Si vous avez des expériences, positives ou négatives sur cette méthode, des conseils, sources ou outils, je vous invite à laisser des commentaires sur cet article.

Cette entrée a été publiée le Mercredi, 25 octobre 2006 à 11:30 et est rangée sous .NET/C#, Architecture Logicielle. Vous pouvez suivre les réponses sous cette entrée avec le flux RSS 2.0. Vous pouvez laisser une réponse, ou utiliser un rétrolien (trackback) à partir de votre site.