北京.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，但這些“法寶”之間無法集成，仍然是開發團隊中所有人的痛。
所以，微軟在今年開始預備普及“大乘真經”，使開發人員不僅可以“渡”自己，還要“普渡眾生”。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。
選擇了方法論，并且創建了團隊項目(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孫悟空，金箍棒助力十萬八千里
在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 當中，我們可以將其做成“代碼片斷”，對其進行歸納治理。
面對已有的項目，我們經常會有更改某些代碼的需求，這就是“重構”，在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，可以為網絡應用進行壓力測試。但這款工具僅能進行“黑盒測試”，無法進行“白盒測試”，而且測試所反應出來的性能問題是以計數器等形式給出，需要測試人員以及開發人員合作，根據經驗分析代碼找出代碼中的性能瓶頸。
好處當然還遠遠不止于此。幸好，在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則是微軟將這些內部工具的集大成者，并且提供了更多的自定義以及擴展，以使其不僅適合大型開發團隊，同時也適合小型開發團隊。
