一、質量的相對概念
1、多數比較上進的程序員，都希望自己的代碼作品是優雅的、高質量的、別人看到能贊賞不已的。但事實上，緊迫的進度壓力使程序員沒有太多時間思考，匆忙趕出功能后，趕快測試發布趕快交付給客戶。因此有人提出需要重構，有人提出各種測試方法，計算“每千行代碼缺陷率”，以追求“零缺陷”為目標?？傊鄶导夹g人員認為“質量越高越好”。這里有個典型例子《養成重構的習慣有多重要》，很有代表性。
2、現在我們假設一種場景，筷子的質量。
首先你到了五星級酒店，它的筷子必須是如象牙般優雅，筆直而對稱，沒有任何瑕疵斑點，有合適的重量手感，等等，也就是說五星級酒店對筷子的質量要求是很高的，否則客戶會發飚。
然后你到了一家路邊的快餐店，順手拿過來一雙“一次性筷子”，拆開后發現毛刺很多容易扎手，甚至筷子有點彎曲，但你還是湊合著用了，或者實在無法忍受就扔掉再拿一把，因為這是在路邊快餐店，用戶對筷子的要求是低的。
如果你把快餐店的筷子賣到酒店里會發生什么情況？質量太低客人無法接受。如果五星級酒店的筷子賣到快餐店會發生什么情況？用戶不需要那么好，也不愿意付那么多錢。所以同樣做一個筷子，卻對質量有不同要求。
所以說：質量是相對的。
3、基于第2點，所以一味追求“高質量代碼”，把“高質量目標”凌駕于“企業贏利目標”之上，是多數技術人員所犯的錯誤。
二、對質量目標進行逐級分解和控制
多數成熟度不高的軟件公司會有一定的質量控制方法，但將其用于所有的項目和所有的軟件層面。我認為這是一種資源浪費。適度降低對外圍層次、用戶需求弱相關、使用頻度低模塊的質量控制，會給項目帶來進度和成本上的收益。
比如下面這個案例。這是一個比較成功的網游公司中，項目代碼分層控制情況
大家特別注意每個層次的質量要求，從“不使程序崩潰、邏輯正確不使程序崩潰即可”，到“技術總監親自開發測試，不許別人碰里面代碼”分級管理，越是核心部分對代碼質量要求越高，從開發人員的級別/背景/資歷/審核人員級別/測試方法上可以體現出來。而4和5兩層比較外圍的代碼， 只要實現功能就可以了， 我閱讀了這些代碼并在其中開發過一小段時間，里面到處充斥著“壞味道”的代碼，程序員都是邊改邊罵，但這并不影響這個游戲有60萬的活躍用戶和300萬以上的注冊用戶，給公司帶來強勁的現金流。而這套對質量進行分級控制的方法，則是技術總監傳授講解給我的。
（表格中代碼開放度僅供參考，小公司是輸不起的，看看pudn.com上那些把老東家代碼拿出來開源的人渣就知道了）
大家知道項目的時間-質量-成本鐵三角， 如果把上面5層代碼的鐵三角列個表格出來，大致如此（我們假設在每個軟件層面投入的成本是一致的）
越是核心層（1層）, 其需要修改的代碼越少，但是對代碼執行的時間和空間開銷越小, 穩定性要求越高. 越外圍的代碼（5層）, 針對需求而開發和改動的代碼量越大。選取上表中的1層、5層、平均畫圖來表示是這樣的：
因此，精益求精、重構只適用于靠近核心的代碼層；而對于外圍代碼層, 由于趕工而導致代碼質量低、放松測試條件，則是完全合理的。
三、結論
所以，在做軟件工程的質量控制時，應該把握軟件的關鍵層面，抓住質量控制的瓶頸。橫向而言，就是開發框架、引擎、核心功能之類的層級；縱向而言，就是用戶使用頻率最高的模塊、和競爭對手做差異化競爭的功能等。對于外圍代碼和次要模塊代碼，前者一般不容易出錯得太離譜（被開發框架限制住），后者使用頻度低，則可以適當犧牲質量以求開發速度。
因此，處于外圍代碼開發的兄弟們就不要成天抱怨、不要提出各種重構要求了。我也曾經在“壞味道”的代碼，確切地說是“糞坑”中撲騰，深知其中感受。但就像魔獸世界里組隊打某些副本BOSS，有的人職責是拉住BOSS的仇恨（拉住客戶），有的人職責是砍BOSS（解決核心模塊），有的人則需要群殺不斷刷出來的小怪（快速開發外圍邏輯）。如果不是這樣的配合，那就會團滅；如果不是這樣的配合，下個月的工資可能就發不出來，不是嗎？