|
Visual Studio Team System中新增的生命期管理无疑是Microsoft在这个竞争已白热化的市场中的又一个重要筹码 Visual Studio与它的竞争对手Eclipse都日益吸引着越来越多的开发者投入到它们中来作为一个源代码编辑器Eclipse已慢慢成长为一个功能齐全反应迅速的工具了但除了重构之外（这也是Java领先多年之处）其他方面已对微软构不成什么威胁了要对这两种开发工具进行量化比较是不可能的但微软似乎总能在代码输入感受及界面效果上技高一筹 Visual Studio Team System（VSTS）是首个交付了软件生命周期管理工具的Visual Studio版本而VSTS Team Server中主要的生命周期管理工具是源代码控制服务器（source control server）及集成的工作项目跟蹤系统（workitem tracking system）这些产品构建于SQL Server 之上因此能有一系统企业级的强大功能如备份复制及具有可伸缩性不过源代码数据库仍是一个不成熟的数字资源样品它的崩溃仍会带来整体上的灾难在采用其他的源代码控制系统时这也是需重点考虑的一个因素 除去SQL Server 的核心健壮性之外VSTS源代码控制服务器也具有某几项使之区别于Visual SourceSafe的特性它工作于HTTP协议并对时区敏感还可把签出的项目存储在一个架子上以便可从多个地理位置进行访问这个架子功能非常方便实用它可让你从多部电脑或多个位置访问源代码而无须签入目前进度中的工作另一个相关的特性是赋予了签入更严谨的策略例如所有签入必须写明一个已指派的工作项目运行无误的单元测试或者已完成FxCop代码分析同样也可以特定的角色（如代码审阅员安全审计员等等）请求批准签入 VSTS中的工程项目管理围绕于工作项目的概念微软使用它来查阅软件缺陷及功能的完成进度VSTS中的工作项目在Microsoft ProjectTeam ServerExchangeOutlookSsharePoint甚至ExcelWord这样的工具之间流动这样的整合集成也是一把双刃剑意味着为了达到协作的目的要付出的价格可是固定不变的恐怕买齐所有这些产品的开发团队还是少之又少的 除去服务端的特性及它们客户端的表现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 ArchitectBorland TogetherVisual Paradigm等齐名的产品不在同一水平上另外与第三方建模工具相比如Visual Object Modeler的Visual UML在这一点上微软自身基础架构之上的建模工具还不是很成熟 除去UMLVSTS中为软件架构师准备的可视化建模工具已为微软摆出了一个强制性的姿态那就是UML并不是它声称般那样有效但在此发行版本中也有一些值得关注的地方如逻辑数据中心系统配置及部署的可视化设计器即使对大公司来说这些也是非常值得关注的产品这些可视化设计器可让你在面向服务的部署中指定软件硬件及网络环境那些服务器刚好装满一个机架的小型或中型企业可能不会把它们当作重要的工具但在中型及大型的数据中心部署上它们的价值就马上显露出来了其实还真想知道这样的部署设计是否真的是在架构师的领域范畴之内呢 别的事不好说可软件详细设计中唯一清楚的一件事就是要编写代码这通常意味着要编写单元测试代码在过去五年中软件开发主流最重要的变化之处是在托管代码解决方案的开发中集成单元测试但在软件架构产品中VSTS并没有使测试工作更轻松如果无法负担美元的Team Suite SKU就必须在可视化建模工具及其他测试工具之间做出选择在这一点上其他测试工具更具有优势 测试员版本 并不是说测试工具是完美的NUint的绿色化干净化的理念使它有一种精炼的纯度使之非常易于集成进你的开发过程中另一方面VSTS允许以多种方法进行测试测试用例能在调试器下运行或单独运行也能选择多个不同的测试等等悲哀的是就测试函数的可伸缩性及多样性来说FIT（测试用例输入输出的表格描述）还未获得支持 开发人员版本 对开发人员来说VSTS在基于Visio建模的基础上整合了单元测试它没有了架构师版本中的以部署为中心的建模器并加载了测试员版本中的测试用例管理工具这种平衡真有点难以取捨如果你能放弃建模器测试员版本的VSTS将是更好的SKU 包装盒中的秘密 在Visual Studio 中微软支持以下四种语言C#Visual BasicC++J#C#与Visual Basic可是 NET中的重量级选手在 NET 中最主要变化的是演变为通用语言运行时库（CLR）而C# 则在其中加入了对泛型的支持最常见的是集合类库混合了特定类中类型安全的泛型 泛型存在的必要性已争论了很久支持动态语言中隐式类型转换的爱好者对类型的安全声明并不感兴趣其他的如Java领域也表示与它们引入的复杂性相比所提供的价值并不明显但就个人来说还是倾向于显式类型转换实际上在Visual Basic的世界中尽管支持泛型但它们似乎总不是讨论的焦点（所有的 NET语言至少必须能使用泛型所有微软公司的语言都能使用及生成泛型） CLR中泛型的实现还是有点意思的在C++中泛型的实例化是在编译时完成的编译器为每个实例化的泛型都生成了一个不相同的二进制类型在Java 中类型安全的语法由一个单一的存储了Object引用的运行时泛型提供支持远比C++所使用的模型简洁得多但却需要对值类型进行装箱及解箱（转换为及转换自基于Object的引用类型）在CLR中如果泛型的类型参数为一个值类型在加载时一个确切的泛型会被实例化这让CLR泛型有了Java泛型中的可伸缩性及简洁性且对值类型来说也提高了执行效率 例是C#及Java的对比程序程序用于显示装箱带来的性能损失编译并运行在一个G位Intel处理器上系统为VMWare中的Windows Server 并为其分配了G的内存对比开发工具为C# 及Java JDK Update C#程序在秒内运行完毕而Java程序在秒内运行完毕虽然这可能代表了最坏情况下的Java表现但也表明装箱的性能损失真的是非常大 例C#及Java的对比程序 //Programcs using System; using SystemCollectionsGeneric; using SystemText; namespace ConsoleApplication { class Program { static void Main(string[] args) { RunIt(); DateTime start = DateTimeNow; for (int i = ; i < ; i++) { RunIt(); } TimeSpan elapsed = DateTimeNow start; ConsoleWriteLine(Elapsed time: {} ms elapsed); ConsoleReadLine(); } static void RunIt() { List<int>[] n = new List<int>[]; for (int i = ; i < nLength; i++) { n[i] = new List<int>(); } for (int i = ; i < ; i++) { n[]Add(); } for (int i = ; i < nLength; i++) { List<int> newArray = n[i]; List<int> oldArray = n[i ]; foreach (int j in oldArray) { newArrayAdd(oldArray[j] * ); } } for (int i = ; i < nLength; i++) { List<int> array = n[i]; foreach (int j in array) { int number = j; } } } } } //GenericValueArrayListTestjava import javautil*; public class GenericValueArrayListTest { public static void main(String[] args) { RunIt(); Date start = new Date(); for(int i = ; i < ; i++){ RunIt(); } Date finish = new Date(); Systemoutprintf(Elapsed time: %d ms finishgetTime() startgetTime()); } static void RunIt() { ArrayList<Integer>[] n = new ArrayList[]; for(int i = ; i < nlength; i++){ n[i] = new ArrayList<Integer>(); } for (int i = ; i < ; i++) { n[]add(); } for(int i = ; i < nlength; i++){ ArrayList<Integer> newArray = n[i]; ArrayList<Integer> oldArray = n[i ]; for(int j : oldArray){ newArrayadd(j * ); } } for (int i = ; i < nlength; i++) { ArrayList<Integer> array = n[i]; for(int j : array){ int number = j; } } } } 除了泛型C# 主要是通达LINQ（Language Integrated Query 语言集成查询）的一块踏脚石这又是一种横跨微软公司语言产品的功能但这次是由C#充当开路先锋LINQ整合lambda函数类型推论及智能库设计的目的是为了使查询不只是数据库而是任意集合能成为主流编程语言中的第一类要素 回过头来看Visual BasicNET这个版本试图在抗拒转向完全面向对象语言的社区中重拾对VB的激情诚然比较以前的版本这次的VBNET无疑是一次巨大的进步但社区中的很多人也感到即使不能带来任何好处也必须重写以往工作正常的程序所以我们看到一些人继续使用VBNET而更多的人转向了C#还有一些人则全然抗拒 NET另外Visual Basic引入了My命名空间其目的是为了降低基类库（Base Class Library）的复杂性及提供对对象的即时访问还加强了编辑并继续这个深受大家喜爱的功能 在年秋天的专业开发者大会上微软展示了代号为Visual Basic Orcas的部分功能包括了LINQ及在语言字面上直接整合XML如同C#一样这个版本的VB看起来会有重大的改变了 最后来看一下C++此次Visual Studio中最重要的变化无疑是C++/CLI了这是一个对C++语言的扩展并为托管对象添加了句柄作为第一类语言实体在某种意义上来说其与指针的语法非常相似并且使用gcnew关键字来实例化可垃圾回收的托管对象另外确定性最终清理也是一大亮点相比Visual Studio 通过双下划线来访问托管对象句柄的语法似乎更容易使用一些 另一方面Visual C++ 在编写桥接或混合托管与非托管代码的程序上显示出了无与伦比的可伸缩性你可编写完全控制进入点的DLL在各种字符串表示法之间进行转换还可充分挖掘Win的性能并且在托管领域微软可能会说对CLR而言没有比C++更低级的语言了包括CLR自身（虽然有点夸大但也可看出微软在重心在何处） 对本地程序（native program）开发者来说Visual C++ 也有几项让人感兴趣的特性比如标准库中增强了安全的函数实现strcpy_s()以及其他OpenMP的实现其允许对特定类型的操作以共享内存的方式并行处理（一般运用于数组算法上）可支持更多的设备等等最后要提一下对基于Windows的SmartPhone本地程序开发现在可在Visual Studio中完成了 既然说到设备就讲得再开一点Visual Studio 扩大了语言可支持设备的范围NET Compact Framework也有了P/Invoke功能如果缺少它那将是开发中的一个重大障碍现在NET Framework已有了位及位版本在位Windows上将会并行运行以避免DLL Hell当然了Visual C++ 也能进行本地位程序开发 IDE 唯一能与Visual Studio 中窗体构建器相抗衡的也就是同一阵营中Visual Studio 的了Windows Form是生成基于窗体的本地应用程序的最好的高产出库而ASPNET 也是一名不容小觑的选手如果功力不深恐怕如今也不会在动态网站方面得到广泛的应用虽然有点主观但微软的设计时体验似乎反应越来越快也越贴近用户基类库（Base Class Library）的广泛应用价值无法估量其庞大的体积在很大程度上也因为有了代码智能感知（Intellisense）已不再是什么问题了 另一个不得不提的地方就是重构不幸的是微软在这个领域的第一次努力并不怎么让人满意C#只有一小撮的重构功能与IDEA或Eclipse相比无疑显得有点苍白而此时选择JetBrain的ReSharper或Refactor! Pro作为Visual Studio的外接程序（addins）时仍是物超所值 微软把更多的心思放在了代码段（snippets）上面其实质上是模板化的代码块以用于自动化普通（或复杂）任务这看上去是一个好想法但在日常的开发中仍需要亲自把它们合并进源代码也许再过一段时间它所带来的方便才会日益浮现出来因为把实质上一样的属性（property）代码编写上一百万遍并不是一个什么值得鼓励的好方法 尽管Visual Studio 最大的问题似乎存在于重构及代码智能感知（Intellisense）方面但有关于稳定性仍存在着不少抱怨虽然我们对它的稳定性也缺乏比较就个人所知已有三个严重的缺陷它们几乎都与重构或智能感知有关在C#中传递一个继承类型作为类型参数给一个泛型超类（superclass）这是一个合法但很少会遇到的情况能导致CPU自旋锁（spinlock）在VB中在ToString方法中结合使用移位操作会让IDE崩溃在ASPNet中随着网站内页面的增多会导致C#的重构成指数级恶化另外还有报道指设计时异常如由数据绑定控件产生的也会导致IDE崩溃 微软宣称计划为Visual Studio 发布两个service pack第一个于年的月份已经发布致力于解决稳定性问题而第二个有传言指为一个主要的service pack将带来新的功能可能会包括现在CTP版本中的WPF设计器为特定语言改良过的工具甚至很可能把IronPython提升至主流开发语言的位置 结论 Visual Studio Team Suite实质上包括了一大堆的新技术版本的通用语言运行时库及它所用的语言也都在稳定性及执行效率方面经过了改良提高但只有C++/CLI才是本质上新增的改进而IDE也在建模及测试基础架构方面有了两个主要的组件建模架构其发展潜力无可限量但目前仍不及测试架构那般充分开发利用而测试架构几乎马上就吸引了人们的注意力Visual Studio Team Server是微软一个重要的新服务器产品其发展潜力巨大似乎也不会只把重心放在单一的开发论上无论如何微软所作出带来崭新技术的承诺及建立对此版本产品的信心都需要充分利用Team Server 当然了对大多数微软产品零售商及开发者来说升级至这一新的Visual Studio版本大概只是时间的问题以下是正反方观点 正方 ·CLR及基类库（Base Class Library）执行效率及稳定性的提高 ·高产出库如ASPNET及Windows Forms ·可支持目标设备的范围扩大如位及移动设备 ·工作项目跟蹤的可伸缩性及实用性 反方 ·建模工具仍不完整全面 ·可疑的稳定性 ·未证实的服务器组件 ·价格 |
