軟件開發的復雜性 ：
計算機硬件界的摩爾定律(每隔 18 個月計算機硬件的運算速度提高一倍，價格下降一半)適用于硬件的發展規律已經超過三十年了。人們想當然的認為計算機軟件的發展速度和硬件的發展速度相當，但是不幸的是：每次重大的硬件升級之后，隨著更大功能更豐富的軟件的出現，硬件的潛能再一次被無情的榨取殆盡。許多開發的軟件系統不斷的遭受進度延期，人員資金和時間等預算無休止的增加，軟件質量的不斷反復，開發出來的系統對客戶的新需求響應緩慢，更改困難的噩夢。
這樣的現實是由軟件的固有復雜性造成的，軟件不同于硬件的生產過程，是由人的智力勞動完成人的需求到機器程序的翻譯轉換過程。需求可能不清晰，對需求可能出現個人理解上的差異，選擇實現方法的差異，需求的不斷變化，具體實現語言平臺的差異，軟件生產中采用的過程，具體實現人員的變動等等都會對最終的產品產生影響。想象一下，如果一種變化的因素只有兩種可能，那么可以使用簡單的 0 ， 1 表示，只有 10 個變化因素的組合就已經達到了 2--10=1024 種可能性，而實際開發中變化的因素輕易就超過 10 個以上，每個變化的可能是還不止兩個，因此軟件的復雜性很快就會超出人的理解程度。有一句經典的軟件開發名言：世界上唯一不變的是變化本身。不斷出現的變化，會使初始的設計和最終的需求之間的距離越來越遠。
軟件的臭味：
軟件開發，使用，維護中出現了以下的“臭味”：
* 僵化性： rigidity 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其他改動。即使是簡單的改動，也會迫使導致右依賴關系的模塊的連鎖改動。
* 脆弱性： fragility 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。出現新問題的地方和改動的地方沒有概念上的關聯，難以排錯，排錯的過程中又會引入更多的“臭蟲”。
* 牢固性 immobility 很難解開系統的糾結，使它成為其他系統中重用的組件。系統中包含了對其他系統中有用的功能，當其他人想復用這個功能到新的系統時，剝離出獨立的組件的難度遠遠大于重新實現的難度，在時間和進度的壓力下，大多數人只有選擇拷貝涂鴉的方式來實現新系統的功能。
* 粘滯性： viscosity 做正確的事情比錯誤的事情要困難。程序完成正常的功能總是傾向于得到不正確的結果。
* 不必要的復雜性： needless complexity 設計中包含有不具有任何直接好處的基礎結構。為了預防后期維護更改需求的對源碼的修改，在設計之初放置了那些處理潛在變化的代碼來保持軟件的靈活性，這樣的結果是軟件中包含了很多復雜的結構，理解起來更加困難。
* 不必要的重復： needless repetition 設計中包含有重復的結構，而該重復的結構可以使用單一的抽象進行統一。對鼠標右鍵(剪切，復制，粘貼)的濫用，使得完成同一或類似的代碼片斷出現在系統各處。如果原始的代碼段完成的功能需要變化，或者存在錯誤，排錯和增加新的功能變得非常困難。
* 晦澀性： opacity 很難閱讀，理解。沒有很好的表現出意圖。
以上討論了系統構架的臭味，下面討論微觀層次上代碼的臭味：
* 重復代碼：重復的代碼使得更改功能和排錯更加困難。同樣的模塊錯誤會在拷貝粘貼的程序各處多次出現。
* 過長的函數：程序越長越難于理解，這已經是軟件業開發的常識。越難理解的程序，使用維護的成本就越大。如果一個函數的行數超過一頁，很少有人能夠在看到下一頁的時候還清楚的記得函數開頭的變量定義，理解和查錯更加困難。
* 過大類：在一個類中完成幾乎所有需要的功能。十項全能的人是不存在的，軟件也一樣。
* 過長的參數列：如果一個函數(方法)的調用參數過長，使用這個函數的調用過程也一定是困難的。想象一下，調用一個十個以上參數存儲過程會有多么痛苦。這還只是開始，如果任一個參數的定義(名稱，類型)發生輕微的變化，函數的調用客戶端會有多么大的改動。
其他的臭味還有發散式變化，散彈槍修改，依戀情結，數據泥團，基本型別偏執，復雜的 switch 分支語句，平行的繼承體系，冗贅類，夸夸其談的未來性，令人迷惑的暫時值域，過度耦合的消息鏈，中間轉手人，狎昵關系，異曲同工的類，不完美的程序庫類，純數據類(數據啞元)，子類不需要父類的某些特性，過多注釋。詳細的討論可以參見《重構》的介紹。
文章來源于領測軟件測試網 http://www.kjueaiud.com/