“不完美”的VS 2005 Team System(1)

Visual Studio Team System中新增的生命期管理，无疑是Microsoft在这个竞争已白热化的市场中的又一个重要筹码。

Visual Studio与它的竞争对手Eclipse，都日益吸引着越来越多的开发者投入到它们中来，作为一个源代码编辑器，Eclipse已慢慢成长为一个功能齐全、反应迅速的工具了，但除了重构之外（这也是Java领先多年之处），其他方面已对微软构不成什么威胁了，要对这两种开发工具进行量化比较是不可能的，但微软似乎总能在代码输入感受及界面效果上技高一筹。

Visual Studio Team System（VSTS）是首个交付了软件生命周期管理工具的Visual Studio版本，而VSTS Team Server中主要的生命周期管理工具是源代码控制服务器（source control server）及集成的工作项目跟踪系统（work-item tracking system），这些产品构建于SQL Server 2005之上，因此，能有一系统企业级的强大功能，如：备份、复制及具有可伸缩性。不过，源代码数据库仍是一个不成熟的“数字资源”样品，它的崩溃仍会带来整体上的灾难，在采用其他的源代码控制系统时，这也是需重点考虑的一个因素。

除去SQL Server 2005的核心健壮性之外，VSTS源代码控制服务器也具有某几项使之区别于Visual SourceSafe的特性：它工作于HTTP协议，并对时区敏感，还可把签出的项目存储在一个“架子”上，以便可从多个地理位置进行访问。这个“架子”功能非常方便实用，它可让你从多部电脑或多个位置访问源代码，而无须签入目前进度中的工作。另一个相关的特性是赋予了签入更严谨的策略，例如，所有签入必须写明一个已指派的工作项目、运行无误的单元测试、或者已完成FxCop代码分析。同样，也可以特定的角色（如代码审阅员、安全审计员等等），请求批准签入。

VSTS中的工程项目管理围绕于“工作项目”的概念，微软使用它来查阅软件缺陷及功能的完成进度。VSTS中的工作项目在Microsoft Project、Team Server、Exchange、Outlook、SsharePoint，甚至Excel、Word这样的工具之间流动，这样的整合集成也是一把双刃剑，意味着为了达到协作的目的，要付出的价格可是固定不变的，恐怕买齐所有这些产品的开发团队，还是少之又少的。

除去服务端的特性及它们客户端的表现，VSTS还为IDE自身引入了一些新工具，其中最独特之外，是它们构建于测试及建模的新基础架构之上；而VSTS最具争议的方面，是微软已创建了单独的SKU以加强这些不同的基础架构。大多数人是从MSDN的订阅获得Visual Studio安装版本的，对专业开发人员来说，一份MSDN宇宙版早已是事实中的标准。可由于VSTS，订阅者就必须从三个SKU中（架构师、开发者、测试员）选择一个，或为了得到完整的功能而付出更高的价格。

架构师版本

基础架构的建模是其中颇具争议的部分，在这里，当你提到“建模”时，人们会自然地想到“UML”，统一建模语言（UML）在建模领域已有超过十年的中心地位，其规范已由ISO组织标准化。微软对其的态度是，UML存在两个主要的问题：它以描述程序行为为中心，因此会与源代码相冲突；而这些年来表现出的冲突已说明UML太笨拙，难以再扩展。以上两点，事实上的确也存在，但来自竞争对手IBM的Rational才是真正的问题所在。

微软一直在辩驳其在基于Visio的工具中支持UML，并且表示使用新的建模架构，任意第三方也能开发出一种UML建模工具，但实际上却不完全正确。尽管Visio是一个非常不错的工具，但微软的UML工具太简单，完全与那些真正的UML建模工具，如Rational Software Architect、Borland Together、Visual Paradigm等齐名的产品不在同一水平上。另外，与第三方建模工具相比，如Visual Object Modeler的Visual UML，在这一点上，微软自身基础架构之上的建模工具还不是很成熟。

除去UML，VSTS中为软件架构师准备的可视化建模工具，已为微软摆出了一个强制性的姿态，那就是UML并不是它声称般那样有效。但在此发行版本中，也有一些值得关注的地方，如逻辑数据中心、系统配置及部署的可视化设计器，即使对大公司来说，这些也是非常值得关注的产品。这些可视化设计器可让你在面向服务的部署中，指定软件、硬件及网络环境。那些服务器刚好装满一个机架的小型或中型企业，可能不会把它们当作重要的工具，但在中型及大型的数据中心部署上，它们的价值就马上显露出来了。其实还真想知道，这样的部署设计是否真的是在架构师的领域范畴之内呢！

别的事不好说，可软件详细设计中唯一清楚的一件事，就是要编写代码，这通常意味着要编写单元测试代码。在过去五年中，软件开发主流最重要的变化之处，是在托管代码解决方案的开发中，集成单元测试。但在软件架构产品中，VSTS并没有使测试工作更轻松，如果无法负担10939美元的Team Suite SKU，就必须在可视化建模工具及其他测试工具之间做出选择，在这一点上，其他测试工具更具有优势。

测试员版本

并不是说，测试工具是完美的，NUint的“绿色化、干净化”的理念使它有一种精炼的纯度，使之非常易于集成进你的开发过程中。另一方面，VSTS允许以多种方法进行测试，测试用例能在调试器下运行或单独运行，也能选择多个不同的测试等等。悲哀的是，就测试函数的可伸缩性及多样性来说，FIT（测试用例输入输出的表格描述）还未获得支持。

开发人员版本

对开发人员来说，VSTS在基于Visio建模的基础上，整合了单元测试。它没有了架构师版本中的，以部署为中心的建模器，并加载了测试员版本中的测试用例管理工具。这种平衡真有点难以取舍：如果你能放弃建模器，测试员版本的VSTS将是更好的SKU。

包装盒中的秘密

在Visual Studio 2005中，微软支持以下四种语言：C#、Visual Basic、C++、J#，C#与Visual Basic可是.NET中的重量级选手。在.NET 2.0中，最主要变化的是演变为通用语言运行时库（CLR），而C# 2.0则在其中加入了对泛型的支持，最常见的是集合类库、混合了特定类中类型安全的泛型。

泛型存在的必要性已争论了很久，支持“动态语言”中隐式类型转换的爱好者，对类型的安全声明并不感兴趣，其他的，如Java领域，也表示与它们引入的复杂性相比，所提供的价值并不明显。但就个人来说，还是倾向于显式类型转换，实际上，在Visual Basic的世界中，尽管支持泛型，但它们似乎总不是讨论的焦点。（所有的.NET语言至少必须能使用泛型，所有微软公司的语言都能使用及生成泛型。）

CLR中泛型的实现，还是有点意思的。在C++中，泛型的实例化是在编译时完成的--编译器为每个实例化的泛型，都生成了一个不相同的二进制类型。在Java 5中，类型安全的语法，由一个单一的存储了Object引用的运行时泛型提供支持，远比C++所使用的模型简洁得多，但却需要对值类型进行装箱及解箱（转换为及转换自基于Object的引用类型）。在CLR中，如果泛型的类型参数为一个值类型，在加载时，一个确切的泛型会被实例化，这让CLR泛型有了Java泛型中的可伸缩性及简洁性，且对值类型来说，也提高了执行效率。