Loupe

Build 2013: Jour 1 – Improving Developer Productivity and Software Quality with Visual Studio Application Lifecycle Tools

Cette session met en avant principalement 2 outils qui apportent un réel gain sur la compréhension du code visualisé dans Visual Studio 2013.

Le premier outil Code Map est un outil déjà présent dans la version 2012 de Visual Studio, mais encore peu utilisé. Pourtant, celui-ci se montre particulièrement pertinent lorsqu’il s’agit de trouver l’origine d’un bug. Il permet de constituer, au fur et à mesure que l’on navigue dans du code, un schéma représentant l’imbrication des appels/utilisations entre différents objets et/ou méthodes.

Un simple clic droit >> Show in Code Map sur un objet ou une méthode permet d’ajouter cet élément à la Code Map.
L’utilisation de l’option Find All References sur un élément donné permet également d’alimenter la Code Map avec les éléments référençant cet élément.
Enfin il est possible de marquer certains éléments, ainsi que de leur associer un commentaire afin de les noter comme “particulier”, ou tout simplement pour leur ajouter une aide à la compréhension.

Une manière plus naturelle pour générer une Code Map est de profiter de son intégration avec le Débogueur Visual Studio.
En effet, lors du passage en mode Debug, une option apparait et vous permet de générer la Code Map à partir de la Stack Trace de votre session de Debug. Il est alors plus simple de suivre les différents éléments parcouru durant l’exécution de votre application et permet de détecter plus facilement où se trouve la source d’une anomalie donnée.

Le schéma Code Map est généré dans un fichier .dgml mais peut également être exporté et partagé sous forme de fichier image.

Le second outil, fraichement apporté par cette version 2013 de Visual Studio, s’appelle le Code Lens. Celui-ci affiche des informations sur les méthodes de votre code directement dans l’éditeur de texte (Sous forme de texte inline en transparence juste avant votre méthode). On y trouve principalement 4 types d’informations:

  • Le nombre de références qui existent sur une méthode.
    • Cette métrique est particulièrement pertinente pour savoir si la modification d’une méthode donnée peut avoir beaucoup ou peu d’impact sur l’application.
  • Le nombre de tests unitaires qui référencent cette méthode, ainsi que leur statut (réussi ou en échec).
    • Un icône rouge apparait pour signaler la présence d’un test en échec
    • À partir de cette information, il est possible de cliquer dessus pour afficher une pop-up contenant la liste des Tests unitaires référençant cette méthode, et un bouton Run All permet de jouer uniquement ces tests unitaires sans avoir à utiliser le Test Explorer
  • Le nom de la dernière personne à avoir modifié cette méthode.
    • En cliquant sur cette information, une pop-up contenant les informations de contact de cette personne apparait. Elle permet de préparer en un clic un email pré rempli avec l’URL du changeset contenant les modifications effectuées par cette personne
  • Le nombre de modifications apportées à cette méthode
    • En cliquant sur cette information, une pop-up contenant la liste des changesets contenant les modifications de cette méthode apparait.

À noter que Code Lens va apporter un nouvel élément dans l’infrastructure de Team Foundation Server, à savoir une gestion de l’indexation et du cache de Code Lens.

En conclusion, le premier outil Code Map est un outil de choix pour des scénario de correction de Bug, tandis que le second outil Code Lense permet de maintenir meilleur qualité de code à moindre coût.

Photo de profil

Ces billets pourraient aussi vous intéresser

Vous nous direz ?!

Commentaires

comments powered by Disqus