到 2015 2015年 7 月
30 卷数 7
视觉工作室 2015 年-分析与视觉工作室 2015 年代码映射架构
由Blair McGlashan | 到 2015 2015年 7 月
为防止积累的技术债务，以及为保持良好的编码速度，提高您的应用程序的体系结构至关重要。进一步，要快速了解潜在的代码变化是影响的重要的决定是否变化是影响的合理的以及如果是影响的的话，什么及其可能的成本将是影响的。这两个目标需要能够了解您的应用程序的结构和分析那里浮出水面的依赖关系。要解决的第一个目标，通常从顶部工作中，并向下钻取。要解决第二个，一般工作从特定的代码元素中，并向上扩展。
在这篇文章，我们将展示如何可用于代码地图，与在 Visual Studio 2015 企业中，新的功能增强:
- 了解.NET 应用程序的总体结构。
- 分析该体系结构由逐步深入细节浮出水面的依赖关系。
- 了解和分析拟议的变化对代码的影响通过建立从特定的代码元素的依赖关系图。
我们用两个例子说明。自上而下的体系结构和钻井，我们使用"罗斯林"代码库 (.NET 编译器平台)。我们选择这两个原因。首先，它是大的所以了解总体体系结构并不那么容易。(事实上，它是如此之大，您通常需要等待几分钟，从冷启动创建初始的图，而初始生成和索引发生。性能明显优于与更小的解决方案)。
第二，罗斯林是开源的所以你可以容易地亲自尝试一下。要分析拟议的变化的影响，我们用于实验样机从 Microsoft 可视化积压在团队基础服务器 (TFS)。这不是公开的但我们也确定你可以用相似的方式，探讨 Roslyn 代码库中的代码元素，虽然做的原因所以在这种情况下是不太清楚。
我们使用 Visual Studio 2015 企业版，可以从下载的 RTM 版本 bit.ly/1JbLA4S。
了解整体体系结构
我们的出发点是在 Visual Studio 中打开和已建的罗斯林解决方案。去那里，我们克隆了 Git 仓库从 https://github.com/dotnet/roslyn，使用 Git 克隆经验的 Visual Studio 时，团队资源管理器窗口的连接选项卡上，然后打开 RoslynLight.sln 解决方案，自动在打开复制的资源库中找到。然后从视觉工作室 2015 年恢复生成解决方案所需的 NuGet 程序包开发人员命令提示符运行 src\.nuget\NuGetRestore.ps1 脚本。(默认情况下禁用 Windows PowerShell 脚本的执行。启用脚本执行需要提升的命令提示符。如果你不熟悉 Windows PowerShell，你会发现它容易运行该脚本，通过右键单击并选择从 Windows 资源管理器的运行与 PowerShell。)
接下来，我们添加 xunit.runner.visualstudio NuGet 包到解决方案，罗斯林解决方案，是 xUnit 测试，检测由 Visual Studio。最后，我们构建的解决方案 (这可能需要一些时间)。要对此代码的架构立即理解基地，我们没有建设从体系结构菜单中的选项选择生成代码映射解决方案。这创造了一张地图，图中的解决方案结构和项目引用。尤其是，看到引用可帮助您了解如何将解决方案的各部分相关的方式你只是无法欣赏看解决方案，并将勘探项目引用，以找出很多。
一旦所有的二进制文件已被编入索引的代码索引 (本质上是 SQL 数据库存储代码的完整逻辑结构)，地图将转化为你所看到的在图 1。新地图显示很多富裕的依赖关系，颜色编码的传说中 (单击查看代码地图工具栏中的切换按钮)，其厚度反映了相关组件之间的依赖关系的程度。例如，一个绿色的链接指示继承 (和可能的其他属地) 之间相关项目中的类。暗绿色节点表示测试项目。
.png "架构图后索引")
图 1 架构图后索引
在右边的筛选器可以用于排除不同种类的依赖项。例如，您可能想要查看关系图中，与所有的测试代码，隐藏，或隐藏除继承和实现链接的所有链接。您还可以隐藏通用节点并删除包含引用的程序集的外部解决方案的任何节点。这使得它容易看到整个产品代码 (测试不算作产品代码) 的体系结构存在继承关系。
例如，看着继承从与实现关系的根源给你的感觉概念抽象的框架内。你可以看到编译器框架是底部的一切。编译器在框架内，核心也是在此基础上，虽然也有一些似乎源自 CSharp 和 VisualBasic 的层，在核心类是，也许，分层并不十分正确提示。(我们将介绍如何对此进行调查进一步在下一节)。
你可以放大图进一步探讨，地区和甚至选择一个节点或节点 (control 键单击可以有多个选择) 探讨另一个图表中使用新的图，从选择上下文菜单命令。例如， 图 2 说明了做这框架的编译器一部分的核心和 CSharp 亚组的结果。为了在顶部有基类型也被应用于结果底部到顶部布局。
.png "放大的继承层次结构")
图 2 放大的继承层次结构
分析依赖关系
你可以清楚地看到在图 2，核心继承某些类从 CSharp 和 VisualBasic，是有点吃惊。让我们看看如何钻入这进一步来看看什么原因造成的异常。我们开始选择依赖项链接 (核心和之间 CSharp)，选择在新代码地图上显示贡献链接。结果显示在图 3。
.png "结果的钻进核心和 CSharp 之间的联系")
图 3 结果的钻进核心和 CSharp 之间的联系
我们看到一类是在故障，不得不怀疑是否，事实上，VBCSCompiler.exe 项目/程序集真的是核心分组的一部分。也许我们需要重构的解决方案文件夹结构要搬出去。但这种变化之前，我们用代码映射来探索的潜在影响。回到地图所示图 2，我们可以重新启用链接的所有筛选器，以便看到所有程序集，并编辑该关系图将从核心的 VBCSCompiler.exe 节点移动到 CSharp，看到影响依赖关系 (见 图 4)。这似乎当然不会清理的东西，但我们后来发现，Roslyn.Compilers.CompilerServer.UnitTests.dll 也似乎是在错误的地方。探索可以继续本着这种精神。你甚至可以在关系图中以产生一个更清洁的架构，可以用于告知重构的解决方案文件夹，以及更深层次的重构，如分裂类或程序集之间的接口创建新的组节点。
.png "移动节点在依赖关系探讨潜在重构的影响")
图 4 移动节点在依赖关系探讨潜在重构的影响
分析拟议的变化的影响
你可以看到如何检查的体系结构和依赖项的一个代码库从上到下，如何能帮助你找出依赖关系进一步分析。你也看到如何有效地使用代码地图，做这种分析逐步钻进较低级别的明细数据。现在我们要改弦易辙，看看如何可以用相同的功能来探索依赖自底向上的方法，从代码元素开始。尤其是，我们会确定依赖项引用该代码元素和代码元素更改时可能会受到影响。
我们的示例显示从实验原型代码从用于可视化和更改积压在视觉工作室在线或使用分层板的 TFS 的微软。在此示例中，我们想要添加更改直接通过地图，则需要一个新的枚举文字 ChangedProperty 枚举添加工作项的标题的能力。(如果你想要尝试这与枚举在罗斯林代码库中，您可以使用 Microsoft.CodeAnalysis.LocationKind)。然而，首先，我们想要探讨的更改，所以我们在参考 CodeLens 指示器上单击，然后点击代码映射链接显示的影响。
你可以在结果上的看到图 5、 提出的所有方法和其他类成员引用 Changed属性枚举以某种方式。此图显示的成员在建筑方面; 那就是，按类、 命名空间、 程序集和解决方案文件夹。筛选器用于消除解决方案文件夹和程序集，然后更改为从左到右格式的布局。
.png "引用依赖地图后隐藏解决方案文件夹和程序集和左到右布局")
图 5 引用依赖地图后隐藏解决方案文件夹和程序集和左到右布局
这张地图现在可以用来探索可能会受到此更改的代码的所有领域。不只可以你使用地图导航代码 — — 双点击一个节点会把你带到正确的地方的代码 — — 你也可以使用它来看看在设计模式。那么，作为图 5 所示，您可以立即看到方法 SortAndReparent 出现在 StoryMaps.ViewModel 命名空间、 类和任何这些类的代码快速检查发现没有代码更改所需。然而，当你看着 WorkItemsWriter 类中的过程方法，您可以立即看到从关系图中，它在呼唤到子流程，一个为 ChangedProperty 枚举中的每个文本。添加一个新的文字很可能意味着一种新的子流程方法将需要。代码检查证实此 suspicion。
当你经历这个过程，你可以使节点绿色、 红色或其他颜色来指示是否需要采取后续行动 (使用上下文菜单中的编辑子菜单 |标记为后续)，以及将注释添加到包含更多详细信息的关系图 (见图 6)。
.png "注明引用的依赖关系图")
图 6 注明引用的依赖关系图
总结
了解您的应用程序的体系结构是重要的并因此知道任何潜在的代码变化的影响。
在本文中，我们展示了如何使用代码地图，使用在视觉工作室到 2015 年，新的功能增强，了解和分析您的.NET 应用程序的总体结构和检查依赖关系在高水平。这些功能包括:
- 从一个解决方案，使用解决方案文件夹提供初始分组的节点，并根据它们的类型样式项目节点生成大大改善的顶级图。
- 创建新代码的能力将从现有的地图选择映射。
- 节点和链接特别过滤筛选测试和不同类型的链接的能力。
我们然后显示如何钻进一个依赖项链接，在 Visual Studio 2015 年要使用的链接筛选器，可以快速提高挖掘的不必要的依赖性，就到哪里介绍了依赖项的代码行的原因。
最后，我们展示了如何你可以采取自底向上方法与代码映射，通过探索从参考 CodeLens 指标从特定的代码元素，创建依赖关系图，然后使用注释和标记在该图中记录结果的分析进行更改的影响，揭示建议的代码更改的影响。
Stuart Kent 是在微软集团项目经理负责开发人员在 Visual Studio 和视觉工作室在线，专注于控制技术债务和代码共享和协作经验。这包括架构分析工具，CodeLens 和代码搜索方面。
Jean-Marc Prieur 是在微软设想和驾驶经验交付在 Visual Studio 中的高级项目经理和视觉工作室在线专注于控制技术债务，包括体系结构分析工具。
Blair McGlashan 是工程部经理领导总部设在英国剑桥的团队体验专注于技术的债务，包括体系结构分析工具。