戏说Visual Studio Team System

孙悟空，金箍棒助力十万八千里

　　“孙悟空”，也就是我们的架构师，负责把项目需求翻译成开发人员所理解的代码框架，交给开发人员完成相应的功能点。

　　在最“远古”的时候，架构师往往是由开发人员自己来担任的。使用白板或者一张白纸，在上面构划自己对于程序的理解，创建出软件的模块、架构、功能、性能上的需求，然后再进行开发。但后来，软件项目的需求越来越大，而架构师与开发人员的不同点被更多数的开发团队所认识到，从而产生了架构师以及开发人员的角色分工。而架构师也有了专属的设计工具——比如Microsoft Visio Professional，以及自己的设计语言——如UML 等。

　　在Visual Studio Team System 当中，架构师将会得到与.NET代码更加匹配的设计工具，即特意为架构师量身定做的分布式系统解决方案设计器。这个设计器原来的代码名称为Whitehorse（白马），或者正应了由孙悟空降服白龙马的典故。其实架构师也可以分为两种，一种是偏开发环境的，一种是偏部署环境的。对于前者，在Visual Studio Team System 当中提供的是分布式系统设计器；对于后者，提供的是逻辑数据中心设计器。使用分布式设计器，可以将大型的企业级应用使用图形方式进行子系统级的设计，并且最终通过分布式设计器产生真正的业务代码。

　　而在逻辑数据中心设计器当中，所要考虑的则是部署环境的设计，硬件、软件、网络等环境方面的一些约束。在实际的开发情况下，经常会遇到在开发环境下面所有软件都很正常，但部署到生产系统时，则会出现很多问题——这是我们没有预料到的。在Visual Studio Team System中，则提供了校验模式，从而在开发期就可以查找到设计的应用与最终的生产系统之间不匹配的情况，做出处理。

　　在Visual Studio Team System 当中，虽然我们必须使用DSL 来进行架构设计。但如果您还是倾向于UML，借益于其带来的扩展性，第三方厂商可以将UML等类似的架构设计语言无缝集成在Visual Studio Team System 当中。

　　猪八戒，抽出更多时间陪高翠兰

　　将八戒等同为开发人员，可能会伤了很多开发人员的心。八戒虽然懒，但喜欢找一些窍门来完成规定的任务，这也是八戒与开发人员相似的地方。

　　在开发的时候，我们经常会有很多需要重用的代码块。由于这些代码还没有足够成熟到使用动态链接库来进行包接，有时候必须在源代码级对某些参数及代码行进行手工调整。在使用其它IDE时，我们可能把其记录在自己的文件夹中，随时找出来进行拷贝、粘贴。而在Visual Studio 2005 当中，我们可以将其做成“代码片断”，对其进行归纳管理。

　　在使用时，只需要在IDE中使用右键菜单选择调用即可。对于一个团队，可以将这些代码片断的定义文件放在一个开发服务器上，这样整个开发团队均可以共享这些代码片断，提高开发效率。

　　面对已有的项目，我们经常会有更改某些代码的需求，这就是“重构”，在Visual Studio 2005 当中，可以直接在IDE当中完成“重构”，从而使代码架构更加清晰。

　　在相应的开发领域当中，也各自有各自的增强。在Web开发中， ASP .NET 2.0 模型带来了超过50个新出现的控件。以至于目前做一些比较通用的框架，比如用户管理，包括登录、创建用户、更改密码、找回密码等功能，在2.0中再也不需要创建数据表、编写业务逻辑、组织显示控件这样的“八股文”了，只需要将相应的控件拖到界面中就可以。另外，在页面框架领域，则提供了母版页（MasterPage）以及主题及外观（Themes & Skins），使得对于页面布局及体验的管理更加简单，尤其是Web Part 编程模型的引入，使得在Windows SharePoint Service以及SharePoint Portal Server 中的自定义特性，可以由ASP .NET 2.0 自由实现。当然，这一切都是基于ASP .NET 2.0底层的提供模式所带来的
可扩展性。在Windows Application开发当中，也就是.NET开发人员常说的WinForm 开发，在各个方面也有了卓越的改进，比如数据模型的改进、新增加的控件等。其中最重要的是在部署方面所提供的Click Once 模型应该是最重要的，使得Windows Application的自动升级、联机/脱机应用的协调可以不需要编写任何代码，仅仅需要几项配置就可以实现。

　　目前，TDD已经越来越进入大家的视野，并且有很多开发团队在身体力行，比如使用NUnit等相关的工具来进行单元测试开发，从而在开发期就确保软件的质量，符合客户的需求。而在Visual Studio 2005 当中，则内置了VSUnit，帮助开发人员进行单元测试开发。同时，为了保
证客户的现有投资，也提供了NUnit到VSUnit的转换工具。

　　在Visual Studio 2005 当中，内置了一个性能分析工具。通过运行它，分析在当前代码块运行时，硬件、软件、网络等性能计数器的数据可以一览无余；同时，各个方法模块运行的时间也可以显示出来，从而帮助开发人员更简单地查找出性能瓶颈所在，帮助开发人员开发性能更加卓越的软件。

　　Visual Studio 作为开发环境，从1.0 到9.0，一直在帮助开发人员减少工作量，快速地完成开发任务，使开发人员能够不止Enjoy Coding，也可以抽出来更多的时间来Enjoy Life——我们的八戒兄弟也大可以抽出更多的时间去陪陪高翠兰。

　　沙僧，卷帘大将的前世今生

　　沙僧，其在前世是卷帘大将，做着最平凡的工作，却可以达到“大将”的职称。这一点，用于形容我们的测试人员再合适不过了。

　　其实从2004年开始，业界已经开始逐步关注软件的质量问题，从而使软件测试终为大家所重视，部分独立软件开发商已经开始配备专职的软件测试人员。但接下来遇到的问题，有了测试人员，如何来寻找合适的软件测试工具呢？显然，在业界相应的测试工具已经不少，在Visual Studio .NET 2003 的企业版当中也带有一个Microsoft Application Center Test，可以为网络应用进行压力测试。但这款工具仅能进行“黑盒测试”，无法进行“白盒测试”，而且测试所反应出来的性能问题是以计数器等形式给出，需要测试人员以及开发人员合作，根据经验分析代码找出代码中的性能瓶颈。

　　在微软产品组当中，测试人员每天的工作都是从构建版本(Daily Build的产物)开始。这一切起源于微软软件开发的三大过程（关于三大过程的详细定义，可以参看在MSDN网络讲座，我与王晴合讲的PCM 系列课程）之一，即Daily Build（每日构建）。开发团队每天所产生的代码均会自动生成一个可以运行的版本（如果无法自动完成，则需要构建人员手工参与），用于以下目标：

　　1、项目经理可以根据这个版本查看项目的进度。

　　2、客户可以根据这个版本修正自己的需求。

　　3、开发人员可以了解自己所工作的模块与其它同伴是否配合。

　　4、测试人员使用此版本完成自己的测试。

　　好处当然还远远不止于此。幸好，在Visual Studio Team System 当中提供了Team Build，帮助我们完成每日构建的过程。有了Daily Build 的构建版本，我们可以运行相应的测试，对于网络应用，我们可以直接使用其内测的网络测试项目类型，比较类似于Microsoft Application Center Test的测试方法，既可以通过录制测试者的行业自动产生测试代码，也可以进行手工使用C#或者Visual Basic来撰写测试
代码，或者结合使用。一些复杂的测试，可能会需要使用手工测试，在Visual Studio Team System 当中支持手工测试，通过其提供的Word 文档模板，根据测试需求增加相应的测试用例，在运行时，则可以根据应用的表现，选择测试是否通过。

　　另外，由于Visual Studio Team System 提供了丰富的扩展性，在其正式发布之后，会有众多的合作伙伴为其提供各种新的测试类型，使您进行开发。对于应用来说，除了功能测试，还需要进行性能测试，在Visual Studio Team System 当中也内置了压力测试来协助您检查应用的性能情况。创建压力测试是一个向导的过程，首先组合测试类型，可以把网络测试、单元测试、顺序测试等组成一个整体，然后通过配置选择相应的硬件、软件、网络环境，模拟足够的用户数，对应用进行施压，在测试结束后，会自动生成一个测试报告，显示我们所关心的测试数据。

　　如果出现了性能或者功能上的问题，不需要另外打开一个Bug 管理系统提交Bug，而是直接在Visual Studio 当中将其提交为Bug，而且也不需要向开发人员描述Bug的症状、测试环境以及重现步骤，所有的这些都由Visual Studio Team System 自动产生。从而可以使测试人员将更多的精力专注在测试逻辑上。

　　沙僧可以大步流星，跟随整个取经团队快速前进。

　　白龙马，蹄朝西

　　很多外部的开发人员可能都比较好奇，微软是如何开发出来类似于Windows、Office这样大型的软件的。除了良好的开发理论外，其实微软也有一套自己的“法宝”，比如外部所熟悉的RAID 等。而Visual Studio Team System则是微软将这些内部工具的集大成者，并且提供了更多的自定义以及扩展，以使其不仅适合大型开发团队，同时也适合小型开发团队。

查看本文来源