一、質量的相對概念
1、多數比較上進的程式設計師，都希望自己的**作品是優雅的、高質量的、別人看到能讚賞不已的。但事實上，緊迫的進度壓力使程式設計師沒有太多時間思考，匆忙趕出功能後，趕快測試發布趕快交付給客戶。因此有人提出需要重構，有人提出各種測試方法，計算「每千行**缺陷率」，以追求「零缺陷」為目標。總之多數技術人員認為「質量越高越好」。這裡有個典型例子《養成重構的習慣有多重要》，原文和後面的回帖都很有代表性。
2、現在我們假設一種場景，筷子的質量。
首先你到了五星級酒店，它的筷子必須是如象牙般優雅，筆直而對稱，沒有任何瑕疵斑點，有合適的重量手感，等等，也就是說五星級酒店對筷子的質量要求是很高的，否則客戶會發飈。
然後你到了一家路邊的快餐店，順手拿過來一雙「一次性筷子」，拆開後發現毛刺很多容易扎手，甚至筷子有點彎曲，但你還是湊合著用了，或者實在無法忍受就扔掉再拿一把，因為這是在路邊快餐店，使用者對筷子的要求是低的。
如果你把快餐店的筷子賣到酒店裡會發生什麼情況？質量太低客人無法接受。如果五星級酒店的筷子賣到快餐店會發生什麼情況？使用者不需要那麼好，也不願意付那麼多錢。所以同樣做乙個筷子，卻對質量有不同要求。
所以說：質量是相對的。
3、基於第2點，所以一味追求「高質量**」，把「高質量目標」凌駕於「企業贏利目標」之上，是多數技術人員所犯的錯誤。
二、對質量目標進行逐級分解和控制
多數成熟度不高的軟體公司會有一定的質量控制方法，但將其用於所有的專案和所有的軟體層面。我認為這是一種資源浪費。適度降低對外圍層次、使用者需求弱相關、使用頻度低模組的質量控制，會給專案帶來進度和成本上的收益。
比如下面這個案例。這是乙個比較成功的網遊公司中，專案**分層控制情況
層次功能
質量要求
開發者程式語言
**開放度
5任務指令碼、戰鬥劇情、數值設定等外圍指令碼
邏輯正常，跑起來不會導致程式崩潰就行。手工測試
專案策劃組的非程式設計專業人員，簡單培訓後即可編寫
自定義的、類似python的低難度指令碼
所有人可見
4專案外圍**
詳細設計由主程評審，**未評審。手工測試
專案程式組的非主力人員，多數是普通大學本科畢業生
某種業內標準的指令碼語言（商業原因不便透露）
所有人可見
3跨專案使用的遊戲主要邏輯，核心**。如好友系統、聊天系統、幫派系統等
詳細設計由技術總監親自評審，部份模組有做單元測試.
專案程式組的主力人員，主要由重點大學本科生構成
同上，業內標準的指令碼語言
所有人可見
2跨專案使用的開源遊戲引擎，研究/優化/整合/針對特殊需求進行二次開發
技術總監親自帶隊，測試方法未知
研究部成員。基本都是211大學碩士或海歸，計算機或數學專業
c/c++
研究部成員及工程專案的經理、程式經理、測試經理可見。其餘人員不可見
1上面3/4層所用的指令碼直譯器、伺服器分布式框架等
技術總監親自開發和測試。測試方法未知
技術總監和幾個創業元老，清一色海歸
c/c++
僅技術總監和公司股東/創業元老，及幾個專案經理可見
大家特別注意每個層次的質量要求，從「不使程式崩潰、邏輯正確不使程式崩潰即可」，到「技術總監親自開發測試，不許別人碰裡面**」分級管理，越是核心部分對**質量要求越高，從開發人員的級別/背景/資歷/審核人員級別/測試方法上可以體現出來。而4和5兩層比較外圍的**, 只要實現功能就可以了, 我閱讀了這些**並在其中開發過一小段時間，裡面到處充斥著「壞味道」的**，程式設計師都是邊改邊罵，但這並不影響這個遊戲有60萬的活躍使用者和300萬以上的註冊使用者，給公司帶來強勁的現金流。而這套對質量進行分級控制的方法，則是技術總監傳授講解給我的。
（**中**開放度僅供參考，小公司是輸不起的，看看pudn.com上那些把老東家**拿出來開源的人渣就知道了）
大家知道專案的時間-質量-成本鐵三角, 如果把上面5層**的鐵三角列個**出來，大致如此(我們假設在每個軟體層面投入的成本是一致的)
層次質量
進度成本55
1344
2333
3322
4311
53平均3
33越是核心層（1層）, 其需要修改的**越少，但是對**執行的時間和空間開銷越小, 穩定性要求越高. 越外圍的**（5層）, 針對需求而開發和改動的**量越大. 選取上表中的1層、5層、平均畫圖來表示是這樣的：
因此，精益求精、重構只適用於靠近核心的**層；而對於外圍**層, 由於趕工而導致**質量低、放鬆測試條件，則是完全合理的。
三、結論
所以，在做軟體工程的質量控制時，應該把握軟體的關鍵層面，抓住質量控制的瓶頸。橫向而言，就是開發框架、引擎、核心功能之類的層級；縱向而言，就是使用者使用頻率最高的模組、和競爭對手做差異化競爭的功能等。對於外圍**和次要模組**，前者一般不容易出錯得太離譜（被開發框架限制住），後者使用頻度低，則可以適當犧牲質量以求開發速度。
因此，處於外圍**開發的兄弟們就不要成天抱怨、不要提出各種重構要求了。我也曾經在「壞味道」的**，確切地說是「糞坑」中撲騰，深知其中感受。但就像魔獸世界裡組隊打某些副本boss，有的人職責是拉住boss的仇恨（拉住客戶），有的人職責是砍boss（解決核心模組），有的人則需要群殺不斷刷出來的小怪（快速開發外圍邏輯）。如果不是這樣的配合，那就會團滅；如果不是這樣的配合，下個月的工資可能就發不出來，不是嗎？
軟體質量控制
從 源頭控制好質量，團隊中有一人負責整個產品的質量和 審核，對於狗屎 要給予嚴厲的批評。不定期的經常舉行內部培訓，發布後bug彙總總結分析，不斷提高開發團隊技術 水平。發布後出現bug和開發者掛鉤，除了不能解決的，嚴重bug必須在2個工作日內解決，對於不能解決的bug要給出原因 是先期設計導致的？別...
軟體開發質量控制研究
軟體質量是指開發出來的軟體不僅可以滿足客戶明確提出來的要求還要滿足某些沒有明確提出來的要求，軟體質量越高，客戶需求滿足度就越高。軟體專案質量控 制不僅僅是控制軟體設計的最終結果，它其實要求貫穿於軟體設計專案的全過程，從軟體開發初期的客戶需求調查，到最終的軟體交付評審，每個階段都要進行仔細 的控制，才...
軟體分層的思考
先來看一棵樹，有樹幹，樹枝，樹葉組成。樹是乙個整體，我們可以很清晰的識別到一棵樹。成千上萬的樹葉通過樹枝管理起來，非常的整齊。樹枝管理樹葉的結構是一種樹形結構。如果沒有結構化的樹幹樹枝來組織樹葉，樹葉散落一起，樹葉就會非常混亂。樹形結構非常好的管理了複雜性，樹形結構是大自然創造使用非常普遍的設計，你...