Code inspection 的代價

作者：
除了動態測試（執行程式來檢驗是否正確）以外，靜態的檢視也是非常重要的測試方法。檢視的對象可以是 code, 設計文件、需求文件等。當檢視的對象是 code, 我們稱之為 code inspection，一般而言有以下的角色：
  • 撰寫者 (owner)：程式的撰寫者
  • 檢視員 (inspector) ：檢視程式的錯誤，通常都是較為資深或領域專家
  • 速記員 (scriber)：在檢視會議中幫忙記錄
  • 主席 (chair/moderator)：仲裁與協調會議的進行
在分工比較細的組織中，甚至還有報告者，但可以撰寫者來兼任。靜態檢視可以分為幾個步驟
  1. 簡介 (Overview): 由撰寫程式者向所有的檢視者簡介系統內容
  2. 獨立準備 (Individual Preparation): 每個 inspector 獨立的閱讀與檢視程式碼，並將疑問處圈選出來，預備在會議上討論
  3. 檢視會議 (inspection): 檢視程式碼
  4. 追蹤 (follow up): 修正會議上所找出來錯誤，並持續追蹤
依照 Sommerville 書上的資料顯示，簡介、獨立準備、檢視會議 的速度分別是 500, 125, 90 statement/hour, 假設我們完成了一個 1,000 statement 的程式碼，檢視員有 2 位，請問一次 code inspection 花公司多少錢？值得嗎？（請假設每個員工的薪水）。有興趣的大家一起算算吧！

生活樂趣

留言

  1. milua2008年10月25日 上午10:12

    定位資深領域專家

    400/hr (1人月薪約70000元)
    檢視1000 statement 總共要花
    21hr * 2人

    42hr * 400=16800元
    1000行的程式碼 可能賣不到這價錢
    除非專家的行情壓低 或是 程式碼的質量
    達到高價位,要不然不太划算

    而且 程式碼量越多,所花的時間不會等差
    增加,可能會以多倍增加的方式上升

    反之亦然,但
    程式碼很少可能就不需要經由這個過程

    milua

    回覆刪除
  2. Szuwulin2008年10月25日 上午10:20

    今天假設一個專家時薪300大洋（很便宜了吧？）

    整個過程要跑21小時－兩個人就要花12600元

    而試想1000行的程式能有多少價值呢？

    姑且不論設計師的薪水

    以常聽到的笑話－程式五行一元來說

    1000行的程式也不過200元

    我想沒有老闆會幹這種蠢事

    我想到幾個問題

    1.程式的價值被低估－台灣人對於看不到的東西都覺得沒有價值

    2.怎樣的程式需要這樣謹慎的檢查－除非是牽扯到安全問題的ISSUE（像軍方），才有可能這樣子檢查，想當初美國程設這樣發達我想也跟軍方出資有關係。

    回覆刪除
  3. 黃為德2008年10月26日 晚上9:22

    最近一段時間有幾篇文章談論測試的相關問題，尤其薛文的『Code inspection的代價』一文，讓我又想到MDA技術，事實上，利用MDA發展軟體也須要測試，不過是在測試「模式」是否符合需求，因為程式是自動產生，而且程式是由模式(PIM)自動轉換而來，這就符合軟工發展的歷史，即：不斷提升軟體發展的抽象度，當然自動產生的程式如不能100%符合需求，發展者亦可依其須要增減程式，但一般而言數量很少，在我看，似乎不必大陣仗做如此煩冗的code inspection。當然MDA尚有一些問題待解，例目前的UML(包括OCL)寫成的模式是否能充分代表需求(有人提出使用domain-specific lanaguage)，以及程式自動轉換是否完整等等都是MDA的 issues。

    回覆刪除
  4. LLLiu2008年10月26日 晚上11:22

    就我所知，code inspection 的使用時機有兩個：一是協助 debug (自己就是看不出來自己寫的一小段 code 中到底錯誤出在那裡，只好求助他人，所謂旁觀者清也)；另一則是這一段 code 太重要，為了降低險，多找幾個有經驗的人一起看。

    一次檢視的範圍大約是 100~200 行 code 而已，人不是電腦，耐性不足，超過一兩個小時的檢視會議就不再有檢視的效果，有時人多更沒用，因為會相信別人可以看出錯誤在那裡而自己開始打起瞌睡來。

    檢視專家的時薪不會只是 NT$300 的啦，麥當勞工讀生的時薪都是 NT$100 了，所以搞軟體的還在那接兩萬塊的 case 的話，可能是永遠翻不了身的。雖然很多人會想，在台灣寫軟體可能也不需要有 code inspection 的過程，但一旦有機會，我建議你開價 NT$3000 試試看。

    黃教授一直在提倡推動 MDA，我們不妨把 code inspection 的作為提昇到以 UML 為基礎的 high level code 上，一方面傳承軟工的品質精神，一方面也可在高階提昇生產力。希望有一天，這種 code inspection 的價值會達到時薪 NT$30000 的。

    回覆刪除
  5. 黃為德2008年10月27日 下午4:51

    劉教授提議：「不妨把code inspection的工作提昇到以UML為基礎的high level code‧‧‧」，這就是所謂Agile MDA，即視excutable model為基本artifact的觀念。誠如劉教授所言：「在台灣寫程式可能也不需要有code inspection的過程」，其實code inspection仍然須要，只是要inspect是模式，而不是程式語言寫成的程式，如果有一天台灣真能達到這種境界，台灣的軟體工業將可能顯現出另一種面貌，甚至「胎換骨」也說不定，這樣說不知對不對，誠徵專家指教，不過劉教授的「可能」值得探討。至於時薪400或30000本人算術不佳倒無從評價。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容