作者：張克強(qiáng)??? 作者微博：張克強(qiáng)-敏捷307

建議之1:使用好的配置管理工具，也稱為版本控制工具（Version Control), 比如Git，SVN。 請徹底拋棄 VSS，如果是新采用配置管理工具，CVS已經(jīng)不再是選項(xiàng)。 配置管理工具與版本控制工具可以理解為指的是相同工具。

建議之2：拋棄古老的配置管理三庫做法，常說的三庫是指開發(fā)庫（動(dòng)態(tài)庫）、受控庫和產(chǎn)品庫（靜態(tài)庫）；做法是開發(fā)庫->受控庫->產(chǎn)品庫。 在當(dāng)年沒有強(qiáng)大版本控制工具的“古代”，三庫做法是不得不的選擇，而在現(xiàn)代版本控制工具（比如CVS，SVN，Git等）的支持下，三庫做法變得落伍了。

建議之3：納入配置管理的文件的名稱里不要含有版本號(hào)。當(dāng)前的配置管理工具都有強(qiáng)大的版本控制功能，而只要在文件名中加入版本號(hào)，那么相當(dāng)于放棄工具的版本控制功能，而只是把配置管理工具當(dāng)成了普通的存儲(chǔ)空間，就像共享目錄、FTP一樣。

建議之4：必須自己提交代碼，而不是讓別人代勞。有一些團(tuán)隊(duì)為了保證代碼庫的干凈，讓一個(gè)人專門負(fù)責(zé)審核和提交代碼。這并不是一個(gè)好習(xí)慣。源代碼管理并不是為了保持代碼的純凈，起碼在開發(fā)過程中不是這樣。它的目的是讓團(tuán)隊(duì)更頻繁的集成各自的工作，當(dāng)有問題的時(shí)候可以回退。

建議之5： 沒有進(jìn)入版本庫，它就不存在，“工作進(jìn)展的唯一標(biāo)準(zhǔn)就是代碼進(jìn)了版本庫”。如果堅(jiān)持執(zhí)行這一條的話，發(fā)現(xiàn)其他的好習(xí)慣會(huì)隨之而來。把任務(wù)分成小塊所以經(jīng)常提交代碼，更加頻繁的更新，集成代碼。最重要的是，經(jīng)常提交代碼說明了正在做東西。

建議之6：識(shí)別代碼配置項(xiàng)和非配置項(xiàng)。非配置項(xiàng)的例子有target目錄，.class文件，.clashpath,.project, .sonar, thumbs，debug文件夾等等，利用ignore功能把非配置項(xiàng)忽略掉。代碼配置項(xiàng)要完整，在別處能編譯得到相同結(jié)果，但是又不干擾別處的工作環(huán)境。

建議之7：每個(gè)團(tuán)隊(duì)?wèi)?yīng)當(dāng)對代碼配置項(xiàng)和非配置項(xiàng)有所說明，不要假設(shè)每個(gè)團(tuán)隊(duì)新人都是代碼配置管理達(dá)人，小心自以為是的新手加入一些自以為是的垃圾。雖然可以刪除，但發(fā)現(xiàn)再刪除，其本身就是成本。

建議之8：依賴項(xiàng)也需要添加到版本庫，或者維護(hù)好相應(yīng)的庫，其中最重要的是構(gòu)件庫。 同時(shí)也包括圖片，編譯腳本，數(shù)據(jù)庫腳本，自動(dòng)化測試等等。

建議之9：整體環(huán)境在云計(jì)算條件下也是可以成為配置項(xiàng)，環(huán)境中最突出的元素是基礎(chǔ)數(shù)據(jù)。當(dāng)需要多種不同的環(huán)境（比如干凈環(huán)境、仿真環(huán)境、某個(gè)時(shí)間點(diǎn)環(huán)境）進(jìn)行調(diào)試、測試的時(shí)候，得到配置管理的環(huán)境在1分鐘之內(nèi)部署出來，那是多么高效的事情。 測試人員愛死這個(gè)了!

建議之10：避免表面CMMI做法-只管理維護(hù)一個(gè)受控庫，展現(xiàn)給評(píng)估組和應(yīng)付各類檢查，而實(shí)質(zhì)上，項(xiàng)目團(tuán)隊(duì)使用另外的庫開展日常工作，只在應(yīng)付檢查時(shí)才把強(qiáng)制要求的交付物復(fù)制到受控庫。 這種做法滿足CMMI評(píng)估，但實(shí)質(zhì)上沒有發(fā)揮配置管理的更多好處。古老的三庫方案恰恰就是這樣子的。

建議之11：了解最普通的多分支開發(fā)。多分支開發(fā)是最經(jīng)典最常用的模式，無論是否采用，應(yīng)當(dāng)知道多分支是如何玩的：如何拉分支？什么情況下拉分支？如何合并到主干？如何再從主干更新到分支？如何合并到其它分支？什么情況下合并分支后不再維護(hù)分支？合并沖突如何解決？

建議之12：守護(hù)主干+先鋒分支，在主干上修復(fù)缺陷以及應(yīng)急響應(yīng)，而把新功能放到分支上開發(fā)，在分支上測試通過后合并到守護(hù)主干，再發(fā)新版。這種做法適用于承擔(dān)大量運(yùn)維修改的情景。也許多數(shù)軟件產(chǎn)品屬于這種情景。

建議之13：主干開發(fā)。主干開發(fā)有兩種情況，情況1：還沒有掌握分支開發(fā)，只會(huì)主干開發(fā)；情況2：充分掌握了分支開發(fā)之后，主動(dòng)選擇主干開發(fā)。顯然的建議是指情況2。主干開發(fā)風(fēng)險(xiǎn)高，效率也高，值得碼匠們好好研究，實(shí)現(xiàn)高質(zhì)量并且高效的主干開發(fā)并不絕對的困難，收益是絕對劃算的。

建議之14：單分支開發(fā)。單分支開發(fā)其實(shí)與主干開發(fā)沒有本質(zhì)差別，需要采取主干開發(fā)的所有方法，日常工作在分支上進(jìn)行，主干用于應(yīng)急響應(yīng)，兩者需要頻繁的雙向同步。 這樣的模式是兼有守護(hù)主干和主干開發(fā)的好處，但顯然的復(fù)雜度提升了。

建議之15：所有的配置項(xiàng)一起得到基線管理。 主要包括源代碼、文檔和測試代碼，如果不在同一個(gè)庫中，那么需要專門的基線文件來說明同一基線的對應(yīng)關(guān)系。這不能算建議了，這是配置管理的基本要求了，但往往被違反。

參考材料

程序員開發(fā)利器：源代碼管理的十條建議

英文原版 http://java.dzone.com/articles/10-commandments-good-source?

中文翻譯改寫版 ?http://tech.it168.com/a2012/0307/1321/000001321198.shtml

總結(jié)

以上是生活随笔為你收集整理的源代码管理的新15条建议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。