Wednesday, July 29, 2009

使用svn/cvs的重要觀念:人的溝通才能花解程式碼的衝突

使用svn/cvs的重要觀念:人的溝通才能花解程式碼的衝突

幾天前跟一個在軟體業界滿長時間的朋友談程式碼管理的技巧,他說:「小專案一定不用版本控制,而大專案也不一定要用。」

這原因出在他們有一個慘痛的教訓。因為一個程設師忽視其他程設師的錯誤修正,強制把他的patch檔送 VSS 儲存庫(我不是故意指名道姓的,因為事實上,他們是用 VSS),於是1個bug,兩個人解決,也就是等於沒人解決。所以他們衍生出使用版本控制器一定要用 lock 動作,單一檔同時間只允許1個程設師修改,而且不可以破壞別人建立的 lock 。這麼作,只是把 VSS 當作高級 cpoy 指令來用而已。

我跟這位朋友提到使用 svn/cvs 的一個重要觀念:每次 commit 前,要先作 update ,且要看看別人所修改的程式碼及註解,如果與自己的程式發生嚴重的邏輯衝突時,不是硬幹別人的程式,而是打個電話跟他聊聊。

如果軟體公司沒有正確地使用版本控制,而是使用老舊的copy思維。為此,他們會衍生出一種與 copy 相輔相成的工作模式:專業分工。把一個軟體專案元件化、模組化,切完再丟給工程師作,每個人專注自己的小區塊,出了問題自己解決,然後再找一位菜鳥程設師來作 SA ,時間到了,就跟大家要要程式碼,兜在一起跑。這麼作看似解決了程式碼衝突的問題,但也帶來新的問題:

1. 程設師漠視團體的效益,專注自己的效益。
2. 認為只要開幾次會,定下模組溝通的介面,就可以不再溝通了。
3. 少了彼此學習的機會。

可是如果你是正確使用版本控制器的,舉個例子( http://chinesetrad.joelonsoftware.com/Articles/TheJoelTest.html )來說說:「約耳老兄在Excel 團隊時有個規定,每天要將專案編譯1次,且導致編譯失敗的人必須從此負責重新編譯的動作(作為處罰), 一直到有其他人出錯為止。這是個讓人不要導致編譯失敗的好誘因,同時是個讓大家輪流處理重新編譯的好方法,這樣大家都會知道怎麼做。」

當你可以綜觀整個專案時,你可以了解模組之間的關係,可以看看別人的程式精華,可以少1個SA(或許軟體公司對這個比較心動),而你只是花1~3個小時,去學1個你未來都用得到的版本控制器,很划算吧!

等等,我聽到有人反應「如果公司不想讓所有人接觸整個專案呢」!這個例子我有遇到過,曾經就遇到一間公司要求1個工程師把商業邏輯都寫在資料庫的預存程序中,而另1個工程師則是撰寫網頁程式來呼叫這些預存程序,這公司希望產品不要讓1個工程師全把握住。遇到這種例子,就善用 subversion 的權限管理,把一個專案中的兩個模組設定1個只有A工程師可讀寫,另1個只有B工程師可讀寫。但我想,這個管 subversion 的人,該是公司老闆來,還是他美貌的秘書呢!

建立 軟體專案 的訊息溝通網絡組織中最基本也最容易被忽視的第一步,就是使用版本控制工具 (Version control tools)。版本控制工具和訊息溝通有什麼關係?很不直覺,但卻是事實。

以 CVS/SVN 這類工具為例,它傳遞與通知訊息的功能其實比電子郵件更有效率。 SVN 的固定動作是 Update → accept change → Commit → add/modify/revert → Update (repeat) 。往往我在 Update 時,就可以透過其他人在 Commit 時留下的訊息,了解到專案的進程或待辦事項...

2 comments:

鋼之宅工程師 said...

應該是那個貌美的秘書~XD...

鋼之宅工程師 said...

是「化」解,不應該是「花」解吧~(所以是秘書解的~XD)