PageRank



轉移公告

計劃把 http://blog.hoamon.info/ 文章全部轉移至 http://www.hoamon.info/blog/ 這裡,而本 Blogger 站台的文章近 500 篇,我預計在 2014-12-31 前移轉完畢,完成後 http://blog.hoamon.info/ 將只作代轉服務,一律把舊連結如 http://blog.hoamon.info/index.html 轉成 http://www.hoamon.info/blog/index.html ,敬請舊雨新知互相走告。

新文章只發佈在 http://www.hoamon.info/blog/

何岳峰 敬上

2007年3月27日 星期二

使用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 的人,該是公司老闆來,還是他美貌的秘書呢!

1 則留言:

  1. 深有同感。
    運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見

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

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

    回覆刪除

Related Posts Plugin for WordPress, Blogger...