编码质量与编码效率的保证：

       不管采用任何听上去可以保证你软件质量的方法学，最终我们还是会发现他们几乎都在说要达到什么程度、要生成什么成果，每次有关编码的部分他们都会用“具体实现细节就不提了”之类的话搪塞过去，但真实地事实是如果你的编码有问题，所有上面看上去很美的东西无非就是更多的0，没有1的话对项目自身而言没有任何意义，如果说有的话那恐怕就是下一本《The Mythical Man Month》的反面素材而已。

        放到Team概念下，这个问题更具现实意义，对于“下游”的开发人员如果你“上游”的代码库用起来别别扭扭，相信浪费的不仅仅是你的时间，更可惜的是创造性灵感的流失，原因很简单你心情不好。同样，开发组长也希望自己的小组质量上有更多保证，最起码要满足MSDN里《Design Guidelines for Developing Class Libraries》的要求。手工去做这些将消耗作为团队负责人——您本来应该考虑技术架构优劣的很多时间，这还不包括因为与“感觉上”实现不好的开发人员扯皮的时间消耗。这时候，VSTS的静态代码分析（Static Code Analysis）就非常有救场的必要了，它不仅仅是个工具在目标代码上爬了一遍，更多的是他是把以往.Net开发的“准普遍真理”具体体现的过程，其中很多建议都是编译时不会报错，但产品上线后不好定位排查的问题。 

       对于资深的Visual C++开发人员而言，PREfash也许是记忆中一直不错的产品，VSTS也集成了这个产品。相对于Visual Basic.Net、Visual C#而言， Visual C++.Net需要处理的问题往往更为复杂、代码编写上更为灵活，大型的.Net项目中往往还被用来包装以前的头文件、操作系统本地调用，进而向上层C#、VB.Net开发人员提供纯.Net程序集的任务。因此，单纯的类似FxCop方式的检查往往对于这些核心程序集的开发检查力度不够，PREfash与常规静态代码分析一起会诊效果更好。 

       还有一个算不上什么技术含量，但使用不当又总让开发人员觉得别扭的问题就是命名规则的符合性问题。资深的开发人员往往不经意间就用了匈牙利命名法、从Java转过来的开发人员自然习惯于首字母小写的方法命名、纯从.Net起步的开发人员也许更习惯于加个“I”的接口方法命名，当然还有从VB“迁移”过来的开发人员，本来怎么启名字只是个习惯问题，但对于Team而言最好规则就保留一个，不管他“十年前就如何如何”或者“某某知名论坛里说如何如何”。为了提高检查的效率，您可以把这个类Drag and Drop到一个Class Diagram里，直接看类、接口、方法、属性、成员的命名，不过这个过程比较费时，简单的办法就是扩展VSTS的静态代码检查，增加命名规则的检查，那么之后您需要做的就是选择待检查的Project，然后点击“Run Code Analysis”，之后您将至少从三个方面获益：

l         节省了时间。

l         有效的保护了视力。

l         省去了看到不懂规矩代码后心烦的可能。 

除了静态代码分析外，VSTS提供了一个非常“便宜”的代码性能分析的工具，它综合了以往的CLR Profiler、Performance Counter、样本收集技术（Sampling），类比现在电视购物频道常用的一句话，笔者觉得VSTS的这个特性“太超值了”。使用上它也沿续了Visual Studio家族产品操作简单的特质，只要按照操作向导，选择待测试的样本内容，指定要分析（Profile）的内容，之后就可以等待一个分析报告。如果说静态代码分析完成的是普遍经验下代码好不好的问题，那么性能分析做的就是根据您某个应用的个案，分析现有产品模块组成间、代码对象间排列组合好不好的问题，它对于您正在实施的项目而言更具针对性。不过，比起Load Test中结合了应用逻辑的测试不同，性能分析的报告更面向于专业的CLR组成相关的内容，它更加技术化，它的基本原则是让高级开发人员（或专业的优化人员）对于一个“灰箱子”（对比于“白箱子”——原码和“黑箱子”——实际运行系统而言）用10%~30%的精力，找到应用中使用频率占80%~90%但代码行数却只占5%~10%的内容进行优化，简言之就是令优化工作“有的放矢”。相信随着Enterprise Library的普及，大部分开发人员对于Instrumentation这个概念并不陌生，它代表着对于代码各方面详尽度量指标的收集。VSTS的性能分析其实也基于了这个基础，与具有了ObjectBuilder支持的Enterprise Library不同，VSTS采用的是编译期间生成专门面向性能信息记录程序集的办法。 

       其实性能分析的实现原理对于使用.Net进行大型业务系统开发的人员很有借鉴意义，回想一下我们常听到的抱怨“系统慢的太厉害了”、“中午开始单子都跑不了了”… …，其实这些对于解决性能问题而言都太笼统了，即使您通过客服联系到用户明确“您在使用哪个功能做具体哪个操作的时候慢”之后排查一样很困难，原因很简单：系统不是一个人做的，也不是一层的，尤其当某个功能涉及到与外部合作方SOA调用或企业应用间EAI操作的时候，排查就更麻烦了。与其到了生产环境中再费时费力的收集性能指标数据，还不如在设计上就增加相应的特性，尤其可以完成VSTS性能分析本身不能明确表示的工作——您具体业务流程、业务数据相关的性能分析。这样当您的用户再次抱怨系统存在性能故障时，哪一个方法、哪个业务流程后面的系统对象出了问题一目了然，反过来经过一段时间运行后，相关的Best Practice可以再次通过VSTS汇总到您静态代码分析的规则库里。在这个意义上说，VSTS同时作为桥梁和手段，完成了开发Team自身编码质量优化的闭合过程。