【IT168 技术文档】

前言：

       在多数开发人员眼中，Visual Studio已经远不止一个工具，他是实现梦想、发挥自己创造力的舞台。但软件产品作为一个合作的成果需要多个角色的积极参与才可以确保其成功，参与的人员也许是是围坐在一起的3、4名志同道合的朋友、也许是为了某个企业信息化建设集中在一起数十人的专业开发队伍，或者还可能是分布在不同时区为了同一个国际化软件产品协同工作的技术联盟，联盟的的人员可能来自中国、印度、爱尔兰、俄罗斯还有美国… …Visual Studio Team System（VSTS）的诞生很大程度上是为了顺应这个趋势而来，他把项目经理、架构师、开发人员、设计师、测试人员和部署人员聚拢在一个统一的基础下，以一种动态、更具实效的方式通知项目的利益相关人员他们所需要了解的内容，简言之它是糅合了管理内容的开发技术产品。 

       采用VSTS之后第一个要改观的概念就是变Project为Team Project，也许您觉得很久以前自己的Project已经完全Team化了，为什么还要再次强调Team呢？请回想一下您的需求文档保存在什么地方？您的概要设计保存在什么地方？测试中发现的Bug List怎么传递给您的？您最后提交给用户的报告放在什么地方？也许回忆之后Team一词对于某个特定的产品而言就是一个很值得大肆宣传的Logo了。

怎么看待VSTS呢？

       VSTS包括的内容虽然众多，但都是围绕着“开发”这个中心展开的，只不过时间轴线上他被拉长了，从原有的实施阶段被延长到贯穿整个产品开发生命期，人员组成上它也被延展了，从原有的开发人员到涵盖众多角色的团队上。比起“攒鸡毛凑掸子”的多产品开发环境而言，笔者更倾向于单纯统一的产品：一方面技术术语、操作界面的统一可以大大节省参与人员的培训成本，更容易避免实施过程中因为工具平台不同导致的“增值”沟通成本；另一方面开发平台内置组成间的兼容性、协作性也至关重要，尤其当北京的架构设计人员需要远在杭州的开发人员可以及时了解某个模块最新的静态结构的时候，那边的开发人员却因为没有安装特定客户端而无法Get Last，这时怠工就容易出现了，哪怕它仅仅是一个上午，也将很多人的一个上午。

随时随地的测试：

       由于分工的不同，开发与测试部门往往会分开，即便集中工作的项目组也常常被分成不同的小组。因为很多“不是我不小心”的bug一旦被测试出来马上成为项目主管要督促完成的任务，为此很多开发人员也需要经常对自己最近完成的工作进行单元测试。“选择待测试的代码，点击鼠标右键，选择Create Unit Tests”，这就是VSTS中启动一个单元测试需要做的。使用VSTS后笔者更喜欢为自己做的库增加单元测试，毕竟强迫自己把某些类的操作示例写在注释里相对而言是个比较繁琐的事情，因为那里没有语法高亮显示，真的要try还不如做个Unit Test，这样几个月后再拿出来看不至于“陌生”了。当然，放在Team这个概念下，VSTS对于各类测试用例的开发和自动化测试就非常有意义了。随着代码行数的增加，每次底层库的修改似乎都是在“涉冰”，那么最简单且比较有说服力的就是让他Run一下，把修改内容自身及其上层相关对象的测试跑一遍确认没有问题，似乎比拿出一大堆Class Diagram和Sequence Diagram更让上层内容的开发人员放心。项目开发到七七八八的时候，运维人员的参与就会密集起来，“现有的设备上能不能跑起来？”、“单个节点能不能支持40个50K长交易的并发调用？”等等，类似的有技术含量但对于开发人员而言算不上什么创造性任务的事情也是必须要面对的，VSTS的Load Test、Web Test可以大大简化这个工作。配合反射机制的框架代码自动生成可以省去以往设计测试用例过程中“八股”化的代码部分，更多的将注意力专注于具体的用例内容设计上，在完成了每个测试点之后，又可以请VSTS自动的调用这些测试点，我们选择开始测试若干时间后，一份格式工整报告就诞生了。

        不过从实用考虑，开发阶段的测试也许还不算最VSTS闪光点的地方，对于一个大型生产系统的维护而言，VSTS提供的各类测试支持更重要，毕竟开发这个行业流动性相对较大，代码、程序集之间错综绞合的依赖关系也复杂，系统运行半年后的维护性开发，或者某某某二期、3期如果没有以往测试内容的支持，必将是某种程度痛苦的经历。VSTS的测试功能也许在很多同行眼中不算同类产品中最出色的，但他是.Net平台开发最“帖”的，起码可以在很多方面提高开发效率：

l         节省了配置管理的工作，通过VSTS + Team Portal，相关工作无逢的串在一起了。

l         拉进了开发人员和测试人员、部署人员的距离，大家在一个产品框架下流水的完成自己所负责的一块工作。

l         考虑到对于绝大多数项目的适用性，成本因素也许是选择VSTS测试功能的一个理由，尤其是Load Test部分。

l         丰富的报表功能，测试设计方案、测试过程记录、测试结果都可以自动生成，尤其在测试驱动的开发模型下，让每个参与者根据测试内容的反馈“知道”是非常关键的。

l         最后它节省了不少时间，对笔者而言省去重复填写表格后，有了更多时间找茶友聊茶。

规划和设计应用的支持：

       初次看到Distributed System Diagram之后，第一感觉就是“它是我需要的”，而且三个层次划分后的Logical Data Center Diagram、Application Diagram、System Diagram给了解决方案架构师和基础环境架构师沟通的桥梁。

（注：这里解决方案架构师和基础环境架构的称呼时参考Microsoft Certificated Architect的分类标准，分别代表应用设计的Solution Architect和运行环境设计的Infrastructure Architect。）   

而且三个图还可以进行验证，这对于“失之毫厘，谬以千里”的架构设计而言更为重要，虽然说应用设计更多的靠经验，但是做一个好的设计往往还需要灵光一闪，尤其是架构设计人员在着手设计新系统的时候总是喜欢为“以前”所碰到的问题（或按照商标化的说法称之为挑战）提出一些建设性的改进。当然，相对而言这些新的改进不如那些轻车熟路的东西成熟，因此VSTS提供的分布式系统图验证功能就非常重要了。 

同时这些图也方便了架构设计人员和开发人员间的沟通，很多时候设计方案写了1万字的描述性内容也许不如一个设计图来的清晰，原因很简单没有这个图，那么相信在看到那些描述性内容后每个开发人员脑海里都会有副图，而且是一人一幅，与其到了快结项的时候争论“怎么做成了这样”，还不如一开始就统一起来，确保团队的每个开发人员在采掘石块时脑子里已经有了待建立教堂的样子。  

       至于VSTS的Class Diagram Designer是笔者非常喜欢，但又最希望VSTS大力改进的部分：毕竟有了专门的Enum、Delegate图标，对于Inner Class的表示也非常直观；有了专门显示Collection Association关系的连接线让类于类间的包容关系一目了然；对于泛型、继承关系、接口实现关系的显示非常清晰；和自动生成的代码保持同步，大大减少了每个代码块内部框架代码的编写工作量；而且界面看起来也很美观；比起其他类似设计工具而言，它100%纯.Net化。同时，对于UML 2.0类图非常多图标显示的缺失也是非常遗憾的，比如没有命名空间（类比以往产品中的Package）、Association Class、异常（Exception）的专用图标。除此之外，没有状态图、时序图对于开发人员也非常不方便，不能在VSTS中用图形化的方式表示实现层面动态结构的内容是很遗憾的事情。虽然可以借助Visio完成图纸，但是总感觉Visio更像一个画图工具，而非设计工具。另外，因为没有命名空间的支持，因此类图设计器也没有类层次drill in和drill out，不利于从不同层次观察项目的静态结构。现阶段，能用类图设计器完成的图纸笔者尽量用VSTS完成，毕竟它直接联动到后面的实现，实在不够的只好用对UML 2.0覆盖比较全面而且轻巧的StarUML完成。

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

       不管采用任何听上去可以保证你软件质量的方法学，最终我们还是会发现他们几乎都在说要达到什么程度、要生成什么成果，每次有关编码的部分他们都会用“具体实现细节就不提了”之类的话搪塞过去，但真实地事实是如果你的编码有问题，所有上面看上去很美的东西无非就是更多的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自身编码质量优化的闭合过程。