天天看點

[轉載]TFS源代碼管理8大注意事項[轉載]TFS源代碼管理8大注意事項最後

目錄

1. 使用TFS進行源代碼管理

2. 如果代碼沒放在源代碼管理軟體裡,等于它不存在

3. 要早送出,常送出,并且不要覺得麻煩

4. 送出前要檢查你更改了什麼

5. 寫送出資訊時一定要認真

6. 使用代碼審閱提高代碼品質

7. 一定要管理好資料庫的版本

8. 将必要的附屬檔案內建到源代碼管理

源代碼管理軟體是我們工作的必備工具,是許多開發團隊的血液。那麼如何更好的利用TFS進行源代碼管理呢?

為什麼使用TFS,從源代碼管理方面來說,TFS具有以下優勢:

l 與Visual Studio無縫結合,友善開發者進行源代碼管理

l 支援代碼審閱與讨論

l 支援郵件通知

l 支援Web通路與管理

l 支援工作項以及BUG等管理

l 不會上傳.NET開發時生成的垃圾檔案

l 自帶版本合并以及比較工具。

l 支援資料庫版本管理

l 自帶很多管理工具(測試管理器、回報用戶端、界面設計工具等等)

每天重複讀這句話——“使用源代碼管理軟體是唯一的有效措施”。除非你在工作時使用項目的源代碼管理庫來控制代碼版本——否則代碼等于沒有存在過。

顯然你曾發覺在你的本地機器上運作良好的代碼在其他人那裡運作的效果并不理想。是不是?他們不能擷取你的最新版本,他們沒法去歸并代碼檔案,你沒有正确地部署它(參考 you're deploying it wrong)而且如果你的 SSD 硬碟壞了的話你将永遠地失去你的勞動成果。

隻要你保持這個心态——代碼隻有送出後才是真的安全,才是其他良好程式設計習慣的保障。你可以把你的任務劃分成許多很小的單元以便你逐一送出。你需要頻繁地這麼做。你就不必擔心你的硬體會不會出棘手問題。

不過更重要的意義是(至少對于你的團隊上司來說),通過源代碼管理軟體可以看到你做了什麼。使用圖表并列出項目清單是個好方法,不過怎麼知道他們實際上在做些什麼?而使用源代碼管理軟體進行工作就能看得一清二楚了。

關于前面那點,避免“幻影代碼”(就是隻能在你的機器上看到的代碼)的唯一方法是經常送出你的任務并且不要覺得麻煩。它可以解決你的問題,不過這樣做也會對你的工作産生其他的影響:

1. 每個送出的修訂都會為你提供一個還原點。如果你完全把代碼搞砸了(沒騙你,我們都這麼做過),你是希望恢複到一個小時前的工作還是一周前的工作?

2. 歸并檔案時會出現的危險會随着時間不斷增加。歸并檔案一直很麻煩。如果你不是每天都保持送出代碼,某一天你會突然發現你和其他人的更改内容會有 50 多個沖突。你不會為此感到高興的。

3. 它促使你把任務分離成分散的單元。通常人們都是快完成的時候才送出的,因為他們想把代碼做成一個完整的邏輯單元子產品。不過龐大的任務不可避免地要分離出較小的分散功能,而頻繁地送出它們會使你更了解它們,你可以一個個地建構并送出。

如果你做到這些,你的送出曆史不可避免地開始類似于一種半規律的樣式,裡面每個工作日都是在送出任務。當然不總是這樣,也有停下來重構或測試,或者其他合理的活動也會中斷标準的開發周期。

然而,當我在看一個獨立的——尤其是完整的項目時,每當發現我們在一個标準的開發周期裡,有一天或幾天什麼都沒有做,我便會非常擔憂。我之是以擔憂是因為這意味着什麼地方出問題了。一般不是有人正在想方設法要把問題搞定的話,就是因為卡在某個問題上而導緻項目完全沒有進度。無論到底是什麼情況,源代碼管理軟體都會告訴你出現問題了。

往源代碼管理軟體裡送出代碼的步驟其實非常簡單。(你恐怕會困惑上一條為什麼說的那麼麻煩。)一般隻要發現檔案内容有變更時都會不顧後果地把檔案傳上去。像這樣——“我的項目根目錄下有檔案内容變更了,我要快點送出上去!”

如此會發生一件(或兩件)事情:首先,程式員會沒有意識地把目錄下的垃圾代碼檔案也上傳上去。一些人看到類似下面的SVN送出視窗時,就會點選“選擇全部”然後送出——這樣源倉庫裡就會被本不應該存在的未調試的檔案和其他垃圾檔案給弄亂。

[轉載]TFS源代碼管理8大注意事項[轉載]TFS源代碼管理8大注意事項最後

或者是,程式員實際上并沒有檢查他們更改過什麼就把檔案上傳了。當你在工作中處理配置檔案或項目定義檔案時很容易就不經意把那些不想送出的檔案給上傳了,而且那些檔案很可能就被别的程式員用到了。

這是一個古老的諺語(出處不詳),大意是說“寫每一條送出資訊時就好象等下會讀到它的人是一個斧頭殺人狂,而且他還知道你住在哪裡”。如果我是那個殺人狂并在研究你的代碼想追蹤 bug 的話,看到的送出資訊全部都是“代碼更新了”,小心,我會來砍你的!

我的解決辦法就是解釋清楚為什麼要送出新的代碼。每次你對代碼進行更改都是有原因的。可能什麼地方會崩潰。可能客戶不喜歡現在的主題顔色。可能你僅僅要調整一下建構配置。無論是什麼,這都是有原因的而且你要把原因用文字保留下來。

為什麼?這樣做的原因有很多,而且在不同環境下各不相同。舉個例子,使用“曆史記錄”特性或其他類似的功能顯示出誰改了代碼那些地方。如圖:

[轉載]TFS源代碼管理8大注意事項[轉載]TFS源代碼管理8大注意事項最後

這是一個可以随時觀察代碼更改的軟體的一種。無論我想了解一個檔案的完整更改曆史,還是隻想知道團隊昨天做了什麼,留下一個描述性的相關記錄意味着隻要不經意一瞥就能知道是什麼情況了。

代碼審閱可以提高代碼品質。

這一點是我們都知道必須要做的,但是很多人覺得它麻煩。問題是很多(或者是大部分)應用程式沒了資料庫就不能運作。如果你沒有管理好資料庫,那你實際上做的就是一個不完整的完全無用的應用程式。

老實說,如果你沒有管理好你的資料庫版本,你的開發會伴随着很大的問題。在更改資料庫的時候沒有源代碼的管理,沒有還原點,并且很難和團隊密切合作。使用資料庫版本控制系統可以使開發更輕松。

使用VS資料庫項目具有如下優點:

l 支援版本管理

l 便于團隊協作開發

l 支援對不能版本資料庫進行部署

l 支援生成測試資料

l 提供了許多額外的功能與工具:資料庫架構比較、資料比較、生成腳本等

這是特别重要的一點。當應用程式需要外部的附屬檔案存在才可以正常運作的話,把那些檔案也都放進源代碼管理軟體裡!人們傾向于犯的錯誤是,在他們擁有自己設定檔案和本地附屬檔案的環境裡一切都表現得很好就把東西都上傳了,之後覺得沒問題了就不管了。但是其他人不能從源代碼庫裡找到同樣的附屬檔案的話,所有東西都會悲劇性地報錯。

比如,通常我們的項目會引用很多第三方的dll,那麼就應該将這些dll都內建到源代碼管理,如圖:

[轉載]TFS源代碼管理8大注意事項[轉載]TFS源代碼管理8大注意事項最後

希望大家積極讨論并補充。

本文轉自SanMaoSpace部落格園部落格,原文連結:http://www.cnblogs.com/SanMaoSpace/p/5135970.html,如需轉載請自行聯系原作者