 Bonjour, je m'appelle Jean-Marc Prieur, programme manager sur le Team Visual Studio. Dans cette vidéo, je vais vous montrer comment vous pouvez bénéficier des maps de code pour comprendre le design de votre code. Je vais commencer avec une petite review de maps de code, ce qu'ils sont, et ce qui change dans le Studio Visual 2015. Ensuite, je vais faire un démon de trois scénarios qui vont aussi vous donner l'opportunité pour indiquer les nouvelles features dans le Studio 2015. Ces scénarios sont « Utilisez les maps de code pour comprendre les patterns dans le code » « Utilisez les maps de code pour comprendre le design de votre solution » et « Utilisez les maps de code pour aider à retirer les dépendances de l'application ». Finalement, je vais partager avec vous quelques pointeurs aux ressources qui vont vous aider à vous donner plus. Alors, que sont les maps de code ? Il y a des visualisations du design ou de l'architecture de code inférieurs directement du code. Ils montrent les éléments de code dans leur contexte, par exemple les méthodes dans les types, dans les espaces de nom, dans les assemblages et dans les folders de solution. Ils aussi montrent les relations entre ces deux. Le map que je vous montre contient un diagramme d'inhéritage qui va être construit durant notre premier démon. Il est embêté dans la structure de la solution qui est l'objectif d'un autre deux démarches. Le map de code s'évolue de les graphes de dépendance en VS 2010 et nous avons fait un grand investissement en VS 2015 pour les rendre plus utilisables, en particulier sur les 3 scénarios démarchés ici. Les key improvements en VS 2015 sont listés ici. Pour expliquer les features, j'ai besoin d'un code pour travailler avec. J'ai choisi d'utiliser le code d'un tool interne qu'on a construit pour expérimenter de diverses visualisations d'un backlog agile qui a été installé comme des items de travail dans le service de fondation de team ou dans le service de services de studio de visage. C'est un WebApp de .NET MVC qui parle de TFS APIs. Pour ce premier démon, je travaille sur le code et j'ai besoin d'understand les dépendances d'inhéritage dans ce code. Nous allons voir. Donc ici, je suis dans le studio de visage dans la solution de la solution de la solution. Et je l'ai déjà construite. Et je vais créer un nouveau code de code pour aller à l'explorer de la solution et faire un class qui je suis intéressé de travail. Et ce qui s'occupe de travail, le class s'occupe dans le contexte de son espace, l'assemblée et le folder de solution. Et c'est nouveau en VS 2015. Si je vous montre la légende, vous verrez ce que l'icône et les couleurs représentent. La chose grise est vraiment le résultat et il y a la possibilité de l'explorer afin de voir la vraie couleur de ce class. De cette map de code, je peux naviguer les deux codes. Donc j'ai double-clé dans la même façon et je vais augmenter un peu la dimension de la map de code ici. Je peux tester la interface base et right-click et show on code map. D'aujourd'hui, j'ai aussi l'opportunité de faire plus de ceci. Mais pour le moment, on utilise le show on code map et vous voyez que vous pouvez ajouter vraiment des éléments de code de tout, including class view et object model et même le file explorer. Ici, je suis intéressé en construisant la relation de l'hénéritage. Donc, avec cette base de class, je vais utiliser le show all derived types command et ça me montre une map de code avec tous les types de derived. Mais ce n'est pas assez ce que je veux. On observe les couleurs de ces liens. Ces liens représentent les relations et ce que je veux garder c'est les grises qui sont l'implémentation interface et l'hénéritage. Je ne veux pas voir les couleurs et ceci. Donc, je vais à la fenêtre de filtration qui est nouvelle dans l'Hénéritage 2015 aussi et je vais retirer les couleurs, retirer les références, les types de return. C'est plus comme ça. J'ai quelque chose qui ressemble à l'hénéritage diagramme mais ce n'est pas laissé comme je veux parce que je préfère personnellement l'hénéritage diagramme pour avoir les types de base à la top. Donc, je peux changer le layout de localité et cet espace-là par appeler une base à la top. Et là, on y va. Maintenant que nous avons vu que la map de code peut nous aider à naviguer dans le code et à comprendre les patterns dans le code, on va imaginer pour une minute que je regarde une solution que je ne suis pas familiar avec et je veux comprendre les points d'entrée de cette application. Et je veux comprendre l'architecture de la solution et, spécialement, la dépendance avec respect à TFS. Je vais demander une nouvelle map de code pour la solution et je vais avoir un overview un complet overview de la solution. Depuis que je suis intéressé dans TFS, je peux expérer les externaux et trouver ce qu'est la fondation de la team. Je peux les sélectionner. Je right-click pour ajouter un groupe parent dont je vais nommer TFS. Puis, je peux retirer ce groupe TFS au-delà des externaux et supprimer. Je vais relayer. J'ai une belle représentation de ma solution, groupe by solution folder including the test assets et avec les dépendances avec TFS. Si je clique sur quelque chose, je peux voir les dépendances et je observe que, pour exemple, il y a des dépendances sur TFS à l'intérieur des modèles mais aussi sur le site qui est un peu bizarre. Si j'utilise le légende, vous voyez que nous décorons les assemblées avec des icônes dépendant du type de projet including le projet test. Donc, ici, mon objectif serait de comprendre la dépendance sur TFS et aussi trouver les points de l'entrée de cette application pour pouvoir débugner. Donc, je vais exclure les tests assets parce que je suis intéressé dans le code product et expliquer ces deux assemblées et puis quelque chose qui est nouveau en 2015 c'est la possibilité d'établir les niveaux. Par exemple, je ne peux pas représenter le niveau de l'assemblée et ensuite je vois les espaces de nom dans le contexte de la solution folder. Et encore, je peux séparer les fonds de solution et cette fois, je vois les dépendances entre les espaces de nom. Et encore, j'ai la confirmation qu'il y a quelque chose d'accord ici. Les contrôles dans l'application ISP.NET dépendent de TFS. On va revenir à ça dans la troisième démarche. Donc, pour maintenant, je suis intéressé à comprendre les points de l'entrée dans l'application parce que c'est un diagramme layout. Je peux comprendre un peu plus ce qui est ici. Donc, je vais prendre cet espace de nom, créer un nouveau graph de la sélection, expérer et ici, expérer ce groupe. Et j'ai la possibilité maintenant de comprendre ce que les points de l'entrée sont. Et bien sûr, je peux naviguer sur le code pour mettre les points de l'entrée. Nous avons vu dans le premier démarche que nous avons une dépendance inondée. On va maintenant comprendre l'effort pour retirer. Dans le premier démarche, nous avons trouvé que quelque chose était un peu bizarre. En effet, les contrôles sont dépendant de TFS, ce qui n'est pas prévenu. On va essayer de comprendre cette dépendance inondée afin de retirer. Je peux utiliser les links de la sélection dans le nouveau code map pour avoir un vue de ce qui dépend vraiment de TFS. Et vous voyez que ça ne déclare seulement les types et les spécifiques qui sont liés. Et je peux... Donc, je vois ici que l'une classe dans le contrôleur dépend de TFS. Et je peux avoir des détails par faire ça encore. Et maintenant, je vois que seulement en fait, deux méthodes de cette classe ont une dépendance sur TFS et je peux voir les types. Donc, c'est tout pour les démarches. J'espère que vous avez trouvé elles utiles. Pour conclure, ici sont des ressources que vous pouvez suivre pour trouver plus d'informations. J'ai inclusé la documentation sur MSDN, une vidéo sur Channel 9, un blog où nous annonçons et introduisons des nouvelles features et le site de l'utiliseur où vous pouvez poser des suggestions. Merci d'avoir regardé.