Software inspection 不是只有檢驗而已

看了喲哪桑學長寫的〈誰來檢查code?〉，又看了相同主題的「多人大辯論」，心中感觸頗深，大家的論點都圍繞著用 software inspection 來找出程式的 bug ，但這其實並不是 software inspection 的最大價值，因為 software inspection 不是只有檢驗而已呀！

雖然 software inspection 可以發現程式碼的 defect，但它卻不適合拿來做 QC，為什麼呢？因為用 software inspection 來 QC，其實是在殺雞用牛刀。software inspection 的主要目的是促進 team member 共同成長，不要被 inspection 的字面意義誤導了，切記 software inspection 的過程比結果還要重要。

以 TQM 的觀點來看，品質不是檢驗出來的，而是不設計出有缺陷的系統，然而不管你的設計能力有多強，都不能保證我的設計絕對沒有問題，因此在這種思維下，全員參與是一個好主意，因此讓同僚參與 review 工作產出可讓系統更完善，一來可以用比較客觀的方式來確認設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。

所以 software inspection 是一種 QA 的過程而非 QC，亦即它除了重視軟體的產出之外，更重視產能，也就是柯維在《與成功有約》中提到產能必須要與產出平衡。只重視產出而不重視產能，不管開發組織中那個技術最強的人能力有多強，開發過程都會遇到瓶頸，因為所有的產出都要先經過他的 review，他會變成開發系統最大的限制點。

換個角度來看，重視 team member 的產能，review 他們的產出之真正目的在於為了使他們相互觀摩並促進學習成長的良性循環，團隊效能可以不斷提昇及成長，效能提昇了，自然會有更有效率的產出。

Software inspection 並不能取代任何的測試，做 software inspection 之前必須先確認這個程式是可以運作的，已經過測試的，所以不可能藉由 software inspection 靠別人幫你捉 bug。而在 software inspection 會議中，向專案經理、 QA 及 Observer（其他同僚）介紹你的工作產出，而這些與會人員則會 review 你的作品，針對組織或專案各種開發規範及慣例、可讀性、完整性及是否有潛在問題提出看法。review 的時間以不超過 2 個小時為限，而 review 的結果除了成為要求品質改善的表單外，還可以當開發過程中的 lessons learned，誠如我之前在〈軟體開發的團隊綜效〉中所提到的：

記得我在《軟體開發能力的自我組織》中 一文曾提過的：「專案實施 inspection 時，成員的設計能力及 software asset 變得與日俱增，而且在團隊溝通上助益也很大」，就是一種共用件的有效運用，inspection 本身就是一種增進軟體品質的一種共享程序；同時 透過團隊相互觀摩的良性循環，讓有經驗的開發人員分享設計與開發技巧，而達到共享人員的目的；最終的目的其實是要慢慢地形成如 William 所說的軟體資產（software asset）的目標，這不正是共享元件嗎？

開發組織面對規模不經濟，管理能力的改善才是致勝的關鍵，而管理策略採用共用件正是為了去除不必要的複雜度，software inspection 正可以達到這樣的目的。子曰：爾愛其羊，我愛其禮。許多人認為他們沒有時間去做 code review，但它對軟體品質卻有報酬遞增的效果，如果你希望你的開發團隊可以把穩軟體的方向，software inspection 是不可或缺的呀！