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

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

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

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

雖然只是道聽途說，但因為這關係軟體的品質，所以我們不能冒太大的風險，但也不能只是一味地土法煉鋼。亦即，不可以太過仰賴工具也不能完全不用工具，而是要適當地運用工具來提昇我們的開發的效能與品質。那麼工具的使用該如何取捨呢？方法論的實證研究^[1]顯示，大部分方法論使用者認為方法論所帶來的負面因子為：

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

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

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

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

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

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

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

Powered by ScribeFire.

1. Fitzgerald, B. 1998. An empirical investigation into the adoption of systems development methodologies. Info. Manage. 34:317-328.
2. 《周易繫辭下》

基本上我蠻認同程式碼檢驗這個步驟，不過這個步驟不應該是由人來作，更不應該全部交由一個人來作，而是交由一套工具來處理，如此可以省去不必要的人力支出，而且也可以將 Knowledge 分享給 Team 的每一個人。

站在節省人力支出的立場，用工具幫我們檢驗程式碼的想法看起來好像不錯，如果這樣做可以維持程式碼品質而降低人力的花費，當然是最好的選擇，但程式開發的價值首重創意性思考，但工具卻只能預先設好檢驗的規則，在已設定的規則範圍之外，還是有很多 defect 是會被工具忽略掉，但這些 defect 是不應該被忽略的，因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作，交由一套工具來處理，對於改善軟體品質而言，其實是不夠的。

亦即在檢驗程式碼的工作，工具並不能取代人力的，工具最多只能站在輔助的地位，因為審查程式碼並不是 routine job，這個工作需要的是程式實作的專業知識與技巧，要用人的肉眼直接來逐行檢驗，不能由工具代勞。

專案團隊的設計，其實是為了發揮團隊的綜效，讓專案的績效大幅增加。軟體專案團隊要成功，是專注於專業分工與整合團隊綜效相互配合。雖然電腦輔助軟體工程可以簡化設計及開發的過程，讓我們用更有效率的方式來設計程式，但如果太強調效率而缺少整合，效率只是讓無法創造價值的軟體在製品（in-process inventory）不斷地增加而已，徒然增加品質成本。

整合需要團隊有效的互動，也正如敏捷軟體開發宣言所強調的「人本與互動勝過流程與工具」。Software inspection 不是只有檢驗而已，它更重視學習及互動的過程，團隊的學習除了個人知識與技術的單方面獲取外，更重視團隊成員的互動並重視學習的回饋環路。在 software inspection 會議中，團隊成員可以提出個人看法，以積極及開發性的討論來促進集體反思，讓團隊以更有創造力的方式來工作。就像〈反思技術打破』集團性弱智』〉一文所提到的：

一個有學習力的企業要有集體反思的能力。在行動之後，能集體停下來反思的能力，「反思」不同於「檢討」，強調的是調整看事情的「角度」，團隊探究的重點是行動背後的假設，而不是行動本身，當交談的層次進入到假設及認知的層面時，團隊才有可能進入所謂的「雙迴圈學習」，也就是一群人「共同思考」的境界，而唯有在這樣的氛圍下大家才不會相互指責抱怨、不會計較誰的貢獻比較多、不會被認為提出了愚蠢的看法，真正創新才有可能出現！（白國際管理顧問公司總經理，沈沂採訪整理，《21世紀商業評論》2005年11期）

所以，團隊合作重視每一個團隊成員與其互動的過程。在參與 software inspection 的過程中，除了可以達到知識分享的目的外，還會讓成員感到受他有受到重視，無形之間增加團隊向心力及凝聚力。當我們用工具檢驗程式碼時，並沒有辦法享受到這些好處，如同我在〈軟體開發能力的自我組織〉中曾經提到的：

公司缺少了像 Inspection 這樣的機制，任何的抽象思考、建模及各種提昇設計能力的技巧最多只能「孤芳自賞」，對組織開發能力的助益其實是有限的。「獨樂樂不如與眾樂樂」，當專案實施 Inspection 時，成員的設計能力及 software asset 變得與日俱增，而且在團隊溝通上助益也很大，可說是好處多多。

Software inspection 可以用來 QA ，更可以做到 team building，這些都不是用了 CASE 工具就可以勝任的呀！

Powered by ScribeFire.