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
·可支持目標設備的范圍擴大如位及移動設備
·工作項目跟蹤的可伸縮性及實用性
反方
·建模工具仍不完整全面
·可疑的穩定性
·未證實的服務器組件
·價格
From:http://tw.wingwit.com/Article/program/net/201311/13996.html
