邁向高品質程式碼-Zero defects methodoloty
晚上翻了一下約耳趣談軟體，正好看到一個熟悉的名詞：Zero defects。最近一次看到，是在PMP的課程中，在講專案品質控管時，戴明博士所提出的零缺點理論。在約耳這本書中，出現這個名詞，馬上吸引我的注意。
如書中所言，很多程式設計人員聽到這個零缺點理論，一定會嗤之以鼻，因為怎麼可能會有零缺點的程式呢？這就如同管理人員想要用行政命令來降低臭蟲數量一樣可笑。但實際上，這邊的Zero defects指的是，無論何時，都要先修正錯誤才去寫新程式。
程式是會長大的，而且會愈來愈龐大，愈晚修正錯誤，修正時所付出的成本愈高。下午要修正早上寫的程式，易如反掌；今天要修正三天前的程式錯誤，回想一下、Review Code後，應該還是可以在短時間內處理完。但是，如果今天要修正三個月前的錯誤，天啊……甚至最近我身邊還發生，要修正兩年前的臭蟲，這所需花費的時間成本可難估算了。
約耳提到另一個愈早修正愈好的理由，我也非常認同：修正錯誤的時間很難估算，但是寫新程式的時間就相對容易掌握。因為很多錯誤，有時候連要重現錯誤的情境都需要花費許多時間，甚至常常要反覆嘗試錯誤才能抓到問題點。也許解決的方式只是加一行程式，但是為了找出這個解決方案，可能要先花上三天的時間。所以如果工作時程中，包含很多待修正的錯誤，那這個時程恐怕很不可靠；反之，若錯誤都修正，只剩下一堆新程式要處理，則時程可靠性倍增啊！
最後一個支持零錯誤的理由，則很容易說服老闆：面對競爭時，反應可以更快。假設目前手上產品已知的錯誤都已修正，而競爭對手推出了雷同產品，但增加了殺手級的功能搶客戶，這時我們只要把該功能補上現在產品，便可立即上市競爭，不用花費難以預期的時間去修正累積下來的問題。就算不是要上市的產品，而是維運中系統，如果我們維持零錯誤，則客戶提出CR時，我們就相對容易估算時程和立即投入執行，不用再花時間去修正累積下來的問題，也可獲得客戶更高的信任感。
回饋到專案管理上，QP階段，要把這個規範白紙黑字記載下來；QA階段，要檢查待處理錯誤和已處理錯誤的數量，以及登錄和解決的時間差；QC階段，發現錯誤應盡快反應到ICC，並盡速排定時間解決。
--------
沒什麼特別的~
不過是一些筆記而已