善用工具為軟體品質加分

在軟體開發過程中，工具雖然不足以取代人力，但有效地使用適用的開發工具，卻可以讓我們軟體開發得到加分的效果。

不過，在企求開發工具為我們加分之前，我們必須要思考如何才能先拿到基本分數。克明兄最近在〈從軟體架構師(Architect)的觀點來看軟體開發流程〉一文中提到他對工具與自動化的觀點：

“工具” 與 “自動化”，這是流程制訂者與管理者最迷信也最喜歡導入的機制。這兩種當然是很重要，但卻不是最優先考量的，也不是導入後就能解決軟體開發根本的問題的。……而自動化，這個可是有趣的議題。筆者是把有些資深軟體工程師想要開發出把設計圖直接轉換為程式碼這樣的自動化機制，比喻為如同機器貓小叮噹的百寶箱，只要把建築藍圖輸入道具機內，就可以幫你自動產生一棟高樓大廈來！不是不可行，不過，你可能先得要有小叮噹才行。

而喲哪桑學長則告訴我們 Defect Detection Tool 之道聽途說：

幾年前，曾經有朋友跟我抱怨他正在評估的工具，他說用工具掃過他的 source code，找到的 defect 裡，每兩個 defect 就有一個不是真的 defect。……我並不清楚，這類工具一般的 detection rate 與 false positive rate 為何，也不清楚這幾年是否有大幅的進步，更沒有去稽核我朋友的評估過程。這二分之一的 false positive，真的只是道聽途說。

雖然只是道聽途說，但因為這關係軟體的品質，所以我們不能冒太大的風險，但也不能只是一味地土法煉鋼。亦即，不可以太過仰賴工具也不能完全不用工具，而是要適當地運用工具來提昇我們的開發的效能與品質。那麼工具的使用該如何取捨呢？方法論的實證研究Fitzgerald, B. 1998. An empirical investigation into the adoption of systems development methodologies. Info. Manage. 34:317-328.顯示，大部分方法論使用者認為方法論所帶來的負面因子為：

方法論太笨重並且會造成開發過程的惰性。
遵循方法論會干擾實際的開發工作。

而他們也認為方法論也會帶來一項正面因子－在軟體開發過程中促進專案控制與提昇產出的可見度。

所以在開發方法論要導入工具，要注意工具的使用不能太複雜、也不能養成團隊成員太過依賴工具的習慣、避免因為工具的使用而影響實際開發工作、讓工具能幫助我們管理與控制專案的產出並且有助於成員溝通。開發工具的地位應該站在輔助的角色，而不是因為工具而工具。

喲哪桑學長在 defect detection tool 的使用建議我們：

既然工具只是輔助，又假設 false positive 真是問題，我以為在進行 software inspection 前，應該先使用工具掃過 source code，指派人手逐一檢查過工具找出的 defect，修好該修的 defect 之後，再進行 Software Inspection。甚至，工具找出的 defect，若有疑義，也可以做為 inspector 的討論，以決定它是否為 defect。如此一來，才會藉由工具的輔助，好讓人力產生更大的價值。

這正是「既有典藏，茍非其人，道不虛行」《周易繫辭下》的道理，軟體開發的關鍵還是在於人的身上，新方法論強調人本、溝通而非制式的流程、文件或工具。使用工具的目的，其實主要是為了促進個人創意的發揮與其增進相互溝通。現在的整合開發環境（IDE）都做得很好，尤其是使用開放源碼的自由軟體（open source）並不會很笨重，例如 java 社群的 eclipse，可以事先根據過去經驗及業界的最佳實務訂出良好設計慣例的 coding template 的標準，只要讓開發人員在 check in 之前要先 apply 此 template。而 eclipse 會自動檢查程式碼有沒有可能有問題的 code，例如：用到廢棄的 API、區域變數未定初值或變數從未被使用、不需要的 import 等等。還有其 refactor 也很好用，它讓程式碼的重構變得更簡單，如果能加上自動化測試工具（例如 junit），會讓程式碼的品質更可見而更易於管理與控制。

總之，好用的工具要靠專案團隊正確的使用才有加分的效果，如果只有工具而沒有善用的知識，有比沒有還更可怕，不可不慎呀！

Please follow and like us: