發表文章

目前顯示的是 10月, 2015的文章

使用source control system的壞習慣

很多人都有使用 source control system(SCM) 的好習慣,不過我也發現到有些人在使用SCM時的壞習慣,以致於把使用SCM的好處給抵消掉不少,有時候甚至還得到反效果。其實我自己在初期剛使用SCM時,也是犯了同樣的壞習慣,一直到後來才意識到。因為這個壞習慣是那麼的不明顯,以致於大多數人都很自然而然的犯而不自知。 這個壞習慣是什麼呢? 那就是把SCM當作是純粹的source code database來使用。為什麼我會說這是一個壞習慣(或錯誤)?雖然說source code database原本也是SCM的功能之一,但我認為並不是最重要的功能,最重要的功能應該是在control這個字的功能上面才對。SCM讓我們對source所作的修改、內容增減作記錄,每一筆記錄就是一個版本,每一個版本的所有變動都匯入到database裡。我們可以透過SCM client介面對這些版本作檢視,隨時可以更新到任意版本,隨時復原所作的變動回到指定版本。 在軟體開發過程中,有一大半都是在對原有的程式作修改,尤其是在大型的系統來說,有更多的小修改、錯誤修正等等。想想看,假如某一個版本的修改(bugfix或功能增減)僅在一個版本裡面就包含了十項、數十項或甚至數百項或更多的修改會是什麼樣的情況? 當開發的軟體一切都正常的時候,把SCM當作source備份的database沒什麼問題,事實上也很合適。但是軟體的開發並不那麼簡單順利,尤其是大型系統的開發過程中,絕對會產生大大小小的bug。這些bug有時候很容易就可以解決修正,在一些複雜系統裡面,有些bug需要利用復原回朔(revert)的功能,將修改的內容還原到舊版本,一個一個版本往上回朔檢查問題是從那一個版本開始發生的。利用這個雖然辛苦但有效的土方法來找到問題發生點的版本,再去比對所作的修改是那裡產生的問題再去修正。 想想看當你用回朔法找到你想要解決的問題發生的某個版本,而在這個版本裡面有一堆的修改,裡面混雜了多個bug修正、功能增減等等會是什麼樣的情況?這一定會增加debug的難度。如果在這個版本裡面只包含對一件事情的修改,無論是bugfix或是功能增減,要回朔到上一個版本一定是件相對容易多的事情。一個版本只作一件事情,同時對於review也會是一件單純的事情。 所以對於SCM的使用,我永遠都秉持底下幾個