Sept. 10 21:14~21:40
軟體開發團隊若是有使用持續整合系統的習慣,久了之後自然會想在續整合系統上面掛上一些靜態程式碼檢查的工具,例如PMD、Checkstyle、Findbugs。使用這些工具固然可以找出一些程式碼中潛在的問題,但是實務上這些工具也經常會發出「假警報」,也就是說找出「不是問題的問題」。這還不打緊,這種工具一使用下去,如果「火力全開」(打開所有檢查規則),找出來的問題數量經常多到嚇人,少則數十個,多則數千個都可能。
俗話說「法不責眾」,用工具找出來的「嫌疑犯」那麼的多,哪有時間一一去釐清。所以雖然這些靜態程式碼檢查的工具經常被提及,但實務上要真正派上用場卻還是需要動點腦筋。
前幾天讀了一本對岸的書《精益軟件度量》,書中提到一個做法,還算有點意思,在此介紹給鄉民們參考。
***
方法其實很簡單,就是「不論找到的問題有多少個,至少先確定這些問題的數量不會增加」。簡而言之,就是要先hold住現場狀況。假設鄉民們用Findbugs找出自己的系統中有500個潛在的問題,團隊暫時沒時間也不想去處理。沒關係,但日後不管是誰簽入(check-in)程式碼到版控系統中,要確定Findbugs所找出的問題不可以超過500這條基準線。也就是說,不要讓問題繼續惡化下去。
如果鄉民們簽入的程式碼會讓Findbugs找出2個新的問題,但是你又不想處理這2個問題,那怎麼辦?很簡單,你可以選擇去修正原本程式碼中的那500個問題,只要改掉2個,這樣一增一減有問題的總數還是500,你便可以把程式碼簽入到版控系統中。
***
Teddy以前也用了好幾年的Findbugs,經常也讓那些為數眾多的「嫌疑犯」搞得很不開心。雖然一有機會便會安排時間去檢視這些Findbugs找出的問題,陸陸續續也把「嫌疑犯」的數量降低了不少。但經常又因為有人簽入新的程式碼,嫌疑犯」的數量又默默地增加。
所以,不管有沒有安排時間去檢視靜態程式碼工具所找出的問題,確保新增加的程式碼不會讓既存系統的品質變得更糟,也不失為一種使用「軟體度量」的方法。
***
友藏內心獨白:這樣也行耶。
確實是個不錯的方法 ~
回覆刪除此即所謂的童子軍原則
回覆刪除