你不是一個人在戰鬥——VS2010對團隊開發的支援

“偉大的使用Visual Studio的程式員，他繼承了整個項目團隊的光榮的傳統，蓋茨大叔這一刻靈魂附體！程式員一個人，他代表了整個團隊良好溝通精誠合作的曆史和傳統！在這一刻！他不是一個人在戰鬥！還有項目經理，架構師，測試人員！他不是一個人！！”

<b>個人程式英雄主義一去不複返了</b>

圖1，程式超人

求伯君！

王江民！

鮑嶽橋！

以及如雷貫耳的蓋茨大叔！

他們憑借自己的個人才華，在當年用雙手敲出了風靡一時的各種軟體，最終成就了自己，成了令衆人羨慕的英雄。

現在的程式員越來越多，但是“英雄”的名字再也沒有聽說過了。在那個蓋茨大叔認為“無論對誰來說，640K記憶體都足夠了”的年代，程式員可以憑借自己的個人才華，用雙手敲出一個獨立的軟體，一個完整的系統，就像求伯君的WPS，王江民的防毒軟體一樣。但時至今日，要完成一個比較完善的軟體，對于單個的程式員來說，已經是不可能完成的任務，隻能是湯姆克魯斯的“MISSON IMPOSSIBLE”了。Windows XP的代碼超過2000萬行，加上各種其他元件，代碼量接近3000萬，那麼Windows 7的代碼量就更加可想而知。如果現在你還夢想着一個人完成一個系統，我隻能說你是程式員中的“唐吉坷德”，是當代的“愚公”！

如果你還做着個人程式英雄的美夢，是時候醒醒了。

<b>你不是一個人在戰鬥</b>

<a target="_blank" href="http://blog.51cto.com/attachment/201010/184751207.jpg"></a>

圖2，你不是一個人在戰鬥

從你的座位上站起來，看看人頭攢動的開發大廳：

對！你不是一個人在戰鬥！

現在已經不是一個人就完成整個軟體，包辦軟體整個生命周期的需求分析，架構設計，編碼，測試甚至後期的維護的時候了。現在的軟體開發，已經成為一個分工明細的工廠化制造。在為了開發一款軟體而組織起來的項目組中，有負責管理的跟技術無關的項目經理、有負責系統整體架構設計的架構師、有負責編碼實作的程式員、也有負責測試的測試人員。

在以往的時候，項目中的這種種角色，各自使用自己的工具軟體進行工作，長槍短炮齊上陣好不壯觀。項目經理使用Project，Excel等制定項目計劃，進行任務劃分和配置設定，架構師使用Rose進行架構設計，而開發人員則使用Visual Studio進行編碼，到了測試人員那裡，他們又使用開源的CPPUnit等工具進行測試。這些工具軟體被簡單松散地集合在一起，幾乎可以稱得上八國聯軍了。各個軟體之間無法進行資訊流的溝通，軟體開發流程和項目管理流程兩者是完全分裂開的，導緻資訊在項目内部的阻塞，造成項目成員之間的溝通不暢。

微軟看到了這種軟體開發趨于團隊作戰的趨勢，同時也看到了這種近乎單兵作戰各自為政的現狀，是以在Visual Studio Team System中提供了協同一緻的應用程式生命周期管理工具，讓參與軟體開發的各種人員，從架構師到開發人員，從項目經理到測試人員，都能夠更加容易地在整個應用程式生命周期管理(ALM)過程中進行協作。是的，你不再是一個人在戰鬥！

Visual Studio Team System為項目團隊中的各種角色提供了合适的工具，并且将這些工具以Team Foundation Server為核心整合在一起，增強了軟體開發團隊中的溝通與協作，使得整個團隊不再是單兵作戰，而是成為一個有機的整體。

<b>We say UML</b>

<b> </b>如果一個東北人到了四川，他可能會懷疑自己是不是還身在中國；如果一個程式員聽架構師對他大講特講什麼系統層次，元件構件，他可能會懷疑架構師是不是來自火星，怎麼就聽不懂架構師所講的東西。這些問題，都是語言不通造成的。

在以往的開發中，架構師用各種各樣的圖表來描述系統的架構，而程式員更容易了解的是實際的代碼。當架構師向程式員描述整個系統架構的時候，程式員往往會因為不熟悉架構師的語言或者表述方式而對系統的架構有所誤解。這就像兩個說着不同語言的人，産生誤解是難免的事情。

現在，我們有了解決的辦法：我們都說UML這種統一的語言。

UML已經成為了模組化語言的事實标準，架構師都習慣使用它來描述系統的各種行為，而程式員也能夠很好地了解這種模組化語言并用程式設計語言将它們實作。這樣，當架構師和程式員都在說同一種語言的時候，團隊中的溝通就更加順暢了。

圖3，We say UML

在Visual Studio 2010中增加一個新的項目模闆，叫做“模組化項目”，通過這個模闆，我們可以快速建立一系列UML圖，目前可以建立UML 2.x 13個圖中的5個，另外還可以建立層圖和有向圖（.dgml）。

<a target="_blank" href="http://blog.51cto.com/attachment/201010/185001955.jpg"></a>

圖4，Visual Studio 2010中的UML圖

<b>打通團隊溝通任督二脈</b>

<b> </b>

一個軟體項目最大的成本是什麼？

硬體投入？不是！

人員教育訓練？不是！

請客吃飯？不是！

溝通成本！沒錯，溝通成本是一個軟體項目的最大成本。

在一個軟體項目中，因為溝通不暢而引起的成本随處可見：需求分析師因為和架構師溝通不暢，導緻架構師的設計并不是客戶的需求；架構師因為和程式員溝通不暢，導緻程式員實作的并不是架構師的設計；程式員因為和測試人員溝通不暢，導緻測試人員并不能完全覆寫程式員的所有代碼，完成程式員所需要的所有測試工作。可以想象，最後出來的産品跟客戶的真正需求相差了十萬八千裡。

項目組中團隊成員的溝通都很重要，但是最重要和最頻繁的溝通應該是程式員和測試人員之間的溝通：程式員需要根據測試人員的測試報告對軟體進行調試，以修複其中的bug；而測試人員也同樣需要程式員提供的代碼更改，進行更加有針對性的測試。為了打通這項目溝通中最重要的任督二脈，VS2010提供了一系列有力的工具。

在項目實踐中，程式員往往抱怨測試人員送出的Bug無法重制，是一些無效的Bug。現在VS2010提供了一個全新的功能：進階按鍵精靈。它可以全自動錄制測試的整個過程，可回放，可以定制的測試。這樣開發人員在看到測試人員錄制的測試過程之後，可以輕松地重制所有Bug。另外，VS2010中也推出了虛拟實驗室自動化處理方案，名為Visual Studio 2010 Lab Management。當測試人員在虛拟機環境下測試并找到一個軟體Bug的時候，隻用一個基本的點選就可以把整個環境的鏡像點(多個虛拟機)記錄下來。他可以把這個鏡像點的連結，作為附件自動内嵌在Bug報告中，同時可以選擇包含更多的資訊，比如帶時間坐标的視訊，操作記錄，曆史調試記錄等等。程式員得到這個軟體Bug報告後，不必詢問測試人員到底做了什麼，以及重新配置 Bug重制的環境。隻需點選連結，即可得到一個基本的實驗室環境視圖，其中可以包括多個虛拟機環境，他可以用一次點選就可以恢複所需的整個環境狀态。開發人員就擁有了整個環境，包括曆史環境下的調試工具和代碼，找到導緻軟體Bug的事件發生的順序和流程。這樣，重制測試人員送出的代碼再也不是難事了。

另外一方面，程式員在修改代碼之後，測試人員就需要重新運作所有測試用例，雖然代碼修改并不會影響其中的某些測試用例。測試人員常常也會抱怨，程式員為什麼不告訴他們，哪些測試用例受到影響需要再次運作，而哪些測試用例不會受到影響。為了解決這個溝通問題，VS2010提供了兩個重要的新視圖：測試影響視圖(Test Impact View)和代碼變更視圖(Code Changes View)。

圖5，Test Impact View

通過這兩個視圖，程式員可以更加了解代碼修改對測試的影響。當開發人員變更代碼的時候，測試影響視圖會分析哪些測試需要運作以驗證代碼變更。這将幫助測試人員隻運作必要的測試以對代碼變更進行驗證，進而對簽入的代碼充滿信心。新的測試影響視圖顯示了代碼變更後必須運作的測試的清單，同時顯示了每個測試所影響到的代碼變更。而代碼變更視圖則顯示了所有代碼變更的清單，同時顯示了為了驗證這個代碼變更所必須運作的測試。這樣就避免了運作全部測試來驗證某一個小的代碼變更所造成的浪費，使得測試更加高效。

用VS2010打通程式員和測試人員之間溝通的任督二脈，自然整個項目組溝通舒暢，神清氣爽，開發效率自然提高不少。