[M] 在你的經(jīng)歷中，有否切實體會到撰寫文檔會便于以后項目的維護？

[L] 體會太深刻了，我們給HP做的惠普商橋系統(tǒng)，從開始到現(xiàn)在經(jīng)手人估計將近10個了，但是文檔仍然是第一版的，因此需要增加新的功能，如果是一個從來沒有接觸這個項目的人來做，假設(shè)代碼的改動量是200行，但是他首先需要大概的時間來讀以前的代碼。這是沒有文檔的結(jié)果啊。象摩托羅拉，他們的項目組中的任何一個人走掉以后都不會對項目組產(chǎn)生影響，因為他們的文檔做的非常好。

[版本控制]

[M] 在你的開發(fā)過程中，有否使用過版本控制措施？

[L] 我們公司的項目，無論大小都使用版本控制。特別是執(zhí)行CMM標準后，項目一啟動，在版本控制數(shù)據(jù)庫中建立很多的目錄、資源文件等等。其實使用版本控制，是避免兩個人同時操作一份文件，當(dāng)遇到改正的不對的地方時可以回滾，返回到上一個正確的版本。而且萬一程序被幾個人更改后可以記錄更改人的姓名、時間，以利于尋找責(zé)任。其實團隊開發(fā)時，版本控制是必須的措施。而且即使一個人開發(fā)，也建議使用版本控制，比如你更改了某些東西，但是發(fā)現(xiàn)更改的不對，想用Ctrl+Z但又不能恢復(fù)，這時可以使用版本控制的“撤銷簽出”來獲得上一個版本的代碼。

[M] 你在實施版本控制的時候，有沒有發(fā)生過因為人員版本控制意識不強，以及對版本控制工具使用不當(dāng)，而造成的損失或效率降低呢？

[L] 應(yīng)該說在實施版本控制時問題還是很多的，而且有些人對版本控制的認識還不是很清楚，認為版本控制沒有太大的必要。在dot net開發(fā)環(huán)境下，我們曾經(jīng)出現(xiàn)過一些問題，同事剛剛更改的文件，check in 然后check out發(fā)現(xiàn)仍然是原來的樣子，也是說他新更改的代碼丟失了。但是換到另一個的機器上發(fā)現(xiàn)代碼是更改以后的，這樣大概折騰了一上午的時間，后來也不知道什么原因好了，不過倒是后來沒有發(fā)現(xiàn)類似情況。

[M] 你個人對版本控制的實施有何心得？

[L] 其實對于版本控制的心得也談不上，只是有一點source safe的小小技巧或者說小小經(jīng)驗而已。個人理解還處在比較低的水平，個人技巧也只是限于普通的應(yīng)用。在小組協(xié)同開發(fā)過程中，我認為版本控制是必要的，畢竟小組開發(fā)人多，對于某個文件的操作可能同時幾個人都會涉及到，如果沒有版本的控制措施，兩個以上的人可能同時操作同一個文件，這樣會相互沖突，造成代碼的混亂。如果有了版本控制的措施，可以保證一個文件在一個時間只能被一個人使用。當(dāng)遇到修改錯誤的時候可以恢復(fù)到上一次修改的版本，避免發(fā)生不知道修改何處，無法恢復(fù)的問題。還有一個問題是如果某個文件出現(xiàn)錯誤，可以找到后一次修改的人員，到時他想否認都不可能啊。

[M] 如果在版本控制的過程中，由于操作不當(dāng)，或人為疏忽，造成損失，對此有什么補救措施嗎？

[L] 應(yīng)該說在版本控制過程中，不同的人員對于項目文件的操作權(quán)力是不同的。項目經(jīng)理可以add/delete/modify/destory，而項目成員則只能add/delete/modify。因為我沒有遇到過操作不當(dāng)?shù)膯栴}，因此我只能憑借個人的一點理解，給你大概的介紹一下。版本控制的工具對你所作的每一次操作都會記錄下來，保存為歷史記錄，由于項目成員只有delete的權(quán)力，因此如果把某個文件不小心刪除后，應(yīng)該可以通過歷史記錄查找出來，但是如果項目經(jīng)理把文件destory后，在版本控制的歷史記錄中可能找不到了。不過如果項目成員想要修改某個文件，他必須在本地建立一個項目副本，然后本地修改，因此即使在版本控制中把文件刪除，通過其他項目成員的本地副本仍然可以得到某個版本的代碼，但是這個版本是否是新的值得懷疑，因為近該項目成員可能沒有g(shù)et last version。所以如果操作不當(dāng)，或認為疏忽造成損失之后，應(yīng)該可以彌補一部分，但是是否是全部彌補，要試具體情況而定。因此項目經(jīng)理的另一個任務(wù)是每天備份代碼，數(shù)據(jù)庫等重要的項目信息。這樣可以把意外情況的損失降低到小。

[其他]

[M] 對于代碼的規(guī)范以及注釋的書寫，你有何心得呢？

[L] 在我剛剛完成的項目中，有個程序員以前是寫Notes的，對于sql server不是很熟，因此在寫代碼時定義了一堆的tmpstr1，tmpstr2等類似的變量，變量具體對應(yīng)窗體上哪個控件的內(nèi)容，你必須找到變量賦值的地方才能看到變量對應(yīng)的具體內(nèi)容。而且從來不加注釋，整個頁面包含不同的函數(shù)，確使用一個connection鏈接，出現(xiàn)了錯誤，調(diào)試都找不出原因，非常的困難。所以我要求他們必須加注釋，可以說是強迫他們吧。由于工期比較緊倒是沒有要求他改正頁面的代碼。我們公司在制定CMM標準時，整理了一套編程規(guī)范，項目開始時給程序員人手一份。我原來設(shè)想在項目過程中隔一段時間抽出2－3個小時把某個程序員的代碼講一下，人為的讓大家養(yǎng)成比較好的編程習(xí)慣，可惜項目太緊，我沒有執(zhí)行。其實代碼的規(guī)范和注釋可以說是文檔的一部分，規(guī)范好注釋好，對于維護人員來說相對的輕松很多。

[M] 你在回答有關(guān)代碼規(guī)范注釋書寫的問題和版本控制的問題時都提到了CMM，CMM和這些有什么必然聯(lián)系嗎？這些是在CMM中有所提及，還是對CMM實施的一種延伸。

[L] 我覺得CMM可能和這些東西沒有必然的聯(lián)系，因為CMM的培訓(xùn)我們公司近一直沒有做，我只是根據(jù)同事的聊天以及自己的一些個人想當(dāng)然的理解說的，但是我覺得這些應(yīng)該是CMM的一種延伸。在CMM的定義中有一種名為"SQA"的角色，是質(zhì)量保證員，他的工作可能是保證提交給客戶的代碼的質(zhì)量，或許有些版本控制的味道吧。其實代碼注釋的規(guī)范編寫，我覺得我們可以理解為代碼質(zhì)量的一種表現(xiàn)形式。我覺得代碼質(zhì)量的衡量不應(yīng)該僅僅是軟件在客戶處運行正確，沒有bug，還應(yīng)該包括代碼是否利于維護。一個項目維護人員他首先看的可能是項目文檔和代碼，但是由于項目文檔可能不是很全，很正確，因此維護人員的直接的工作可能是看代碼，如果代碼寫的很晦澀，而且又沒有必要的注釋，那么對應(yīng)維護人員來說是很頭疼的事情。這樣可那與CMM的初衷有些背離。

原文出處：http://morningspace.51.net/