La nouvelle version Team Developer de Rosario apporte elle aussi sa part de nouveautés qui vont permettre au développeur un contrôle plus efficace concernant la qualité du code écrit au travers de nouveaux outils dont :
- Le Standalone Debugger
- Le History Debugger
- La gestion des tests unitaires impactés.
- La gestion de l'analyse statique de code par groupe de règles paramétrables.
L'outil pourra donc être utilisé soit :
- à partir d'une clé usb.
- à partir d'un share réseau.
- en copiant les fichiers sur la machine cible.
Ci dessous les étapes pour générer un Standalone Debugger puis le mettre en oeuvre :
A partir de visual Studio lancer la commande Debug / Create Standalone Debugger
L'assistant suivant démarre, spécifier l'emplacement disque pour la création de l'outil (dossier, clé usb ou encore partage réseau :
Cliquer sur Finish pour finaliser le processus
Pour démontrer la puissance de cet outil nous allons effectuer une petite démonstration édifiante :
Créons une petite application Winform avec comme unique fonction un bouton affichant une message box.
Déployons cette application sur une station cliente (attention, le fichier pdb doit être présent sur la machine cible). Ci dessous le contenu du dossier de cette application :
Le développeur doit déboguer l'application sur cette station et va donc générer une instance de l'outil sur sa clé usb ainsi qu'une copie des fichiers C# à déboguer, dans notre exemple, il s'agit du fichier form1.cs par exemple.
Etape 1 : Démarrage de l'application sur la machine cible
Etape 4 : Selectionner le processus de l'application à déboguer puis valider
L'outil augmente la productivité du développeur en réduisant le temps d'investigation sur la cause d'une erreur dans le code ou sa reproduction.
Regardons le fonctionnement de l'outil à travers une démonstration :
Pour cette démonstration nous allons utiliser l'application Patient Monitoring, application de démonstration écrite en WPF fournie avec la VPC Rosario (CTP d'Avril.).
Pour ce scénario de Debug, on démarre l'application à partir de la solution dans Visual Studio en pressant la touche F5
L'application Patient Monitoring s'affiche
Sur activation de l'onglet Details, la photo du patient apparait ainsi que des informations détaillées
Le développeur va alors lancer à partir du menu Debug / Windows la commande Debug History pour accèder à l'historique des actions effectuées durant la session de debug :
Le développeur va donc pouvoir rapidement corriger l'anomalie en consultant simplement les informations fournies en regard de l'icone Erreur : le message est "cannot locate ressource ..."
L'outil fonctionne comme un recorder durant les phases de Debug, le niveau d'informations est d'ailleurs paramétrable comme le montre la capture d'écran ci dessous :
Paramétrage de l'outil History Debugger
Aussitot l'outil detecte les tests unitaires qui ont été impactés par les modifications de code et affichent les tests unitaires impactés dans la rubrique "recommended", ce qui indique au développeur qu'il est recommandé de rejouer ces tests afin de vérifier l'impact des modifications afin d'éviter de potentielles régressions.
Lorsque les tests sont rejoués, ils apparaissent dans la rubrique "Verified"
La fenètre sera remise à jour au fur et à mesure des modifications apportées. Le développeur a donc en permanence une vision de l'impact de ses modifications sur la stabilité de l'application au travers des tests unitaires.
La gestion de l'analyse statique de code par groupe de règles paramétrables
Suivant l'adage bien connu "Trop d'information tue l'information", voici une nouvelle fonctionnalité qui va améliorer le contrôle et le focus du développeur sur la mise en conformité de son code par rapport aux règles appliquées par l'outil d'analyse statique de code fourni avec Visual Studio FXCop (206 règles réparties dans 11 groupes : Design, Globalisation, intéropérabilité, maintenabilité, mobilité, Nommage, Performance, Portabilité, Stabilité, Sécurité et Usage). Dans les versions précédentes, le nombre d'erreurs et de warnings générés par cet outil décourageait rapidement les développeurs pourtant plein de bonne intention au départ. Grace à la nouvelle version de l'outil, il est maintenant possible de simplement Créer des groupes de règles en fonction de critères pertinents par rapport à un contexte projet puis choisir les groupes de règles à appliquer. Cela agit comme un filtre qui va permettre de cibler le travail du développeur. Au travers d'un scenario, nous allons voir comment tirer profit de cette nouvelle fonctionnalité. Lançons tout d'abord une analyse de code statique sur un des projets de notre solution en utilisant la commande "Run Code Analysis" du menu contextuel :
Le résultat de l'analyse laisse apparaitre 18 warnings :
Nous allons modifier le paramétrage en utilisant les groupes de règles paramétrables. Pour cela, il suffit d'ouvrir la fenêtre de propriétés du projet et activer l'onglet "Code Analysis" comme indiqué ci dessous :
On remarque que la configuration en cours est "All Rules" et entraine l'applicaiton des 206 règles.Hors en supposant que la livraison d'une release est proche, nous allons sélectionner l'option "Release Criteria CheckList" dans la liste Rule Set. Instantanément, le nombre de règles tombe à 48, ce qui va fortement limiter le nombre de warnings à traiter par le développeur.
Le développeur relance une analyse sur le projet, le nombre de warning est tombé de 18 à 5
Le développeur ou le responsable projet pourra également créer des règles customs et les exporter sous forme de fichiers XML afin de les distribuer à l'équipe de développement.
Dans ce dernier exemple, on personnalise une règle Custom pour n'adresser que les violations concernant les performances.
En relançant l'analyse, le développeur a isolé les warnings concernant les règles de performances.
Encore une innovation qui va contribuer à la qualité des développements, à disposition des développeurs pour une travail avec plus de productivité.
Aucun commentaire:
Enregistrer un commentaire