北京.NET 技术俱乐部曾经排练了一部话剧《大话VSTS》，通过唐僧师徒四人借助Visual Studio Team System 的力量斩妖除魔，最终完成项目，以戏说的方式对Visual Studio Team System 调侃了一番。笔者有幸参加了此剧的策划，并且先于大家预览了该剧的演出。恰巧《程序员》杂志的编辑要求笔者在本期杂志上写一篇关于“Visual Studio Team System”的文章，故以此开题。
其实在软件开发过程当中，四个人可以组成一个最小的开发团队，完成项目的开发。通过了解西游记的剧情，我们可以为四人分别对号入座，把唐僧看作我们的项目经理，而孙悟空则是软件架构师，猪八戒则喻指为开发人员，沙僧则是称职的测试人员。
如来佛的大乘真经
话说观音大士当日点化唐僧：尔等此时所修乃“小乘真经”，而西天则有“大乘真经”。从而引发了唐僧西天取经的故事。
牵强附会一下，其实开发人员在Windows平台上所使用的开发工具——Visual Studio ——从1.0面世以来，就一直是以开发人员为目标的，帮助开发人员更快速地构建客户所需要的产品。虽然到目前为止，已经发展到了Visual Studio .NET 2003，但其面向开发人员个人，而不注重团队修炼的特征仍然是Visual Studio 的一大弱势。当然，在Visual Studio 的企业版当中，包括了面向源代码治理的Visual
Sourcesafe，以及面向架构师的Visio Professional 以及面向测试人员的Application Center Test，但这些“法宝”之间无法集成，仍然是开发团队中所有人的痛。
在高中政治课上，大家都学过：“有法可依，有法必依，执法必严，违法必究”。对于我们的开发团队来说，“法律” 也仍然有着至高无上的地位。先保证“有法可依”，是一个团队开发软件成功的先决条件，无论你是选择MSF(Microsoft Solution Framework)还是XP（eXtreme Programming）, 总之先要立法——这样就可以使一个开发团队进入到“有法可依”的阶段。而有了法之后，则需要使用各式各样的
工具把法给贯彻下去，否则开发进度可能单纯为了贯彻各种软件开发理论，而不由自主的变慢——所以我们说“有法必依”。但是各个工具假如各自独立、相互没有关系，架构师所设计的架构无法真正落实为代码框架，开发人员设计的代码无法让测试人员进行有效的测试，则无法真正帮助我们提高开发进度——所以要求我们“执法必严”。但是每个软件公司由于资源、人才等的不同，会各自有各自的特征。落实到工具上，则会要求自定义的自由，所以我们还要保证工具可以“违法必究”，从而使不适应的地方得以纠正以使其更加符合不同公司的不同开发制度。
所以，微软在今年开始预备普及“大乘真经”，使开发人员不仅可以“渡”自己，还要“普渡众生”。Visual Studio Team System 是微软即将于今年推出的面向软件开发过程的团队开发工具。在2005 年11 月将会推出英文版，12月一部“Visual Studio Team System”版本的《西游记》，我们可以把团队中的各个角色分别对号入座：把唐僧看作项目经理，而孙悟空则是软件架构师，猪八戒则喻指为开发人员，沙僧则是称职的测试人员。软件开发的道路上，奔走着西天取经的“师父”与“徒弟”则会推出简体中文版。Visual Studio Team System 可以为软件开发团队当中的四种人服务，即项目经理，架构师，开发人员、测试人员。下面，让我们认真看一下这四种角色的法宝。
唐僧，金箍咒下的项目治理
对于项目治理人员，可能并不是很多的人都会熟悉Visual Studio 的IDE环境，但是很多人对于Excel、Project 等工具可能都会非常熟悉。所以，在Visual Studio Team System当中，并没有一个非凡的专门供项目治理人员所使用的版本，而是在Excel、Project 提供了配合VSTS 使用的插件，让项目治理人员可以使用他们熟悉的工具来改善软件开发过程。
使用Visual Studio Team System，在启动一个项目的时候，我们首先可以选择一个方法论的支持，VSTS将会随软件提供两种方法论，即面向小型软件开发团队的MSF 4.0 Agile以及面向CMMI Level 3级开发团队的MSF 4.0 Formal。
当然，由于这种方法论均是使用XML 定义文件进行描述的，所以在未来，我们可以看到更多的第三方的方法论，如XP 等。
选择了方法论，并且创建了团队项目(Team Project)之后，则可以开始进行架构师、开发人员、测试人员的迭代开发过程，在此过程当中，项目治理需要对每种角色的工作量进行统计，从而具体地把握软件开发的脉搏。此时，项目治理人员可以通过工作项(Work Item)为每位角色安排任务，并且随时通过Excel、Project 得到这些工作项最新的状态。从而了解项目的具体过程。同时，由于使用了SQL Server 2005 的Reporting Service功能，对于项目开发的数据进行深入挖掘，可以从更深层次了解项目开发的难点及重点。由于Reporting Service 所拥有的开发特性，使得项目团队可以根据需求，自己定义产生并且输出相应的图表，从而查看到更加具体的数据。
整个项目团队当中所有的数据均保存在版本控制系统当中，包括源代码、架构设计、设计文档、工作项等，均可以保存在SQL Server 2005的数据库当中，并且对其版本进行统一而有效的治理，而不再各自独立地保存在不同的系统当中，对于项目的分支、合并也可以随时进行。同时，VSTS支持HTTP 协议，这样就可以保证异地开发，所以即使孙悟空临时回趟花果山探探亲，也不再担心项目的进度。因为即使在花果山，只要有开发工具，仍然可以继续进行工作，而不会因此中断。再也不需要“唐僧”婆婆妈妈地在大会小会上进行督促，而只需要使用MSF或者其它方法论的“紧箍咒”，就可以进行有效的治理，从而确保项目按时按质的完成。
更多的请看：http://www.QQread.com/windows/2003/index.Html孙悟空，金箍棒助力十万八千里
“孙悟空”，也就是我们的架构师，负责把项目需求翻译成开发人员所理解的代码框架，交给开发人员完成相应的功能点。
在最“远古”的时候，架构师往往是由开发人员自己来担任的。使用白板或者一张白纸，在上面构划自己对于程序的理解，创建出软件的模块、架构、功能、性能上的需求，然后再进行开发。但后来，软件项目的需求越来越大，而架构师与开发人员的不同点被更多数的开发团队所熟悉到，从而产生了架构师以及开发人员的角色分工。而架构师也有了专属的设计工具——比如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则是微软将这些内部工具的集大成者，并且提供了更多的自定义以及扩展，以使其不仅适合大型开发团队，同时也适合小型开发团队。
