程式設計法則和現狀：我們明白自認為明白的東西嗎？

當面對複雜資料時，程式設計格言是如何經得起考驗的？

軟體工程領域的知名專家 Capers Jones

，已經建立了涵蓋20,000個項目的範圍廣泛的項目記錄資料庫，大部分都是大型的。有了這些資料支援，他經常寫文章讨論，哪些活動和方法在實踐中發揮着作用，以及如果可能，它們實際上提供多少提升幅度，它們的成本有多少。在這篇客座編輯裡，他非正式地評價了一些程式設計和業務上的流行“法則”在面對軟體開發現狀時，是如何發揮作用的。

​

Boehm第二法則

原型顯著減少了需求和設計錯誤，特别是使用者錯誤。

由

Barry Boehm

提出的這個法則是有資料支援的。需要說明的是，原型大概占到規劃的系統規模的10%。對于1,000個功能點的應用程式，原型大概會有100個功能點，容易建構。對于100,000個功能點的大型應用程式，原型本身會是一個具備10,000個功能點的大型系統。這得出一個結論，如果可能的話，大型系統最好采用增量式開發的方式。

Brooks的法則

給一個延期的軟體項目增加人手會讓項目更延期。

Fred Brooks

的法則在計算機領域是非常知名的。在一定程度上它有證據支援。應用程式越大，無論怎樣，挽救進度延期都要越困難。對于少于五人團隊規模的小項目，增加一個有經驗的人不會拉長進度，但是增加一個新手就會拉長。對于超過100人團隊規模的大型應用程式，這些項目幾乎總是由于糟糕的品質控制和變化控制而延期。增加人手會因為教育訓練和複雜的溝通管道而趨于減緩進度。

Conway的法則

任何一款軟體都會展現生産它的組織結構。

資料趨于支援該法則。需要說明的是，每個軟體的元件規模都要考慮比對被安排這部分工作的團隊大小。由于很多團隊包含八個人，這就意味着再大的系統或許也要被分解成能夠安排給八個人一個部門的元件，這對于應用程式的總體架構可能不是最優的。

Cunningham的技術債務法則

開發過程中為了節省資金或時間的捷徑和草率将導緻稱之為“技術債務”的後續費用，它或許超過了前期節約的費用。

觀察的資料支援這個基本概念，早期的捷徑導緻昂貴的後續修複。Ward Cunningham的

技術債務概念

是一個偉大的隐喻，但不是一個偉大的标準。技術債務忽視了由于糟糕的品質而被取消的項目。既然35%的大型項目根本不可能完工，這就是一個嚴重的疏漏了。這些失敗的項目成本巨大，但是技術債務為零，因為他們從來不會釋出。技術債務也忽略了訴訟成本和因為糟糕的品質而損失的付款。我在一樁因品質控制引起的訴訟中擔任内行的目擊者，判給原告的損失是修複本身bug帶來的技術債務費用的1,000倍。

Hartree的法則

軟體項目一旦啟動，日程安排在完工之前是個常量。

對于缺少規劃的、普通或拙劣的項目，觀察的資料支援

Douglas Hartree

法則。對于使用了早期風險分析的項目，和由有效方法組成的頂級團隊，這個法則就不是有效的。換句話說，該法則适用于90%的項目，而不是頂級的10%。

Jones的程式設計語言實用性法則

每10年，所有被開發的軟體程式中的90%的程式，隻用到了當時可使用的程式設計語言的10%。

我最初闡述了這個規律。它受1965到2014年資料流的支援。程式設計語言的流行程度非常短暫，從最初的流行爆發到開始消退貌似平均不超過3.5年的周期。沒有人知道這個現象出現的原因。一些語言，比如用在Apple上的Objective C已經持續很多年了。程式設計語言來來去去的原因不得而知，語言持續的原因也不得而知。

Jones的軟體缺陷排除法則

排除缺陷效率高于95%的項目，比排除缺陷效率低于90%的項目要更快、更便宜。

來自于20,000個項目的觀察資料支援這個法則。隻使用測試的項目，通常其缺陷排除效率低于90%，由于拉長測試間隔常常導緻延期。同樣的項目，在測試之前使用檢查和靜态分析，其缺陷排除效率能夠達到99%，通常按時或提前完成，首先要假定合理的日程規劃。糟糕的缺陷排除效率是日程後移的主要原因。

Lehman/Belady的軟體進化法則

軟體必須持續更新，否則它的用處變得越來越少。

軟體的熵或複雜度随時間而增加。

IBM的

Meir Lehman博士

和

Laszlo Belady博士

提出的法則來自于對公司的OS/360作業系統的長期研究。他們已經分别被我确認了。第一個法則直覺上明顯，第二個則不然。為了修複bug和小優化而持續進行的修改随着時間的增長而增加循環複雜度，最終增加軟體的熵或混亂。做為回報，這将放慢維護工作，或需要額外的維護人員，除非取代或重組發生。軟體翻修和重組能夠反轉熵。

Senge的法則

越快就越慢。

Peter Senge

注意到，通常業務企圖加快項目送出的進度，卻往往放慢了進度。這種現象在軟體領域也是如此。當盡量加快項目時，會犯下包括忽視檢查和壓短測試的一般錯誤。它們拉長了軟體開發，而不是縮短。草率的需求收集和回顧，越過設計直接編碼，忽略嚴重的問題，都會發生意外，進而放慢項目進度。為了優化軟體開發進度，品質控制是有價值的，包括測試之前的檢查和靜态分析。

Wirth的法則

軟體性能變慢的速度要大于硬體變快的速度。

在大型機時代，

Niklaus Wirth

提出了這個法則，那時候他好像為大型機工作。然而，對于網絡處理器和并行計算，這個法則貌似不太準确。

Yannis的法則

程式設計生産力每六年翻倍。

我的資料顯示，程式設計生産力和醉漢走路類似，某種程度上是因為應用程式規模越來越大。然而，如果你砍去需求、設計，隻看純代碼工作，這個法則可能更為真實。毫無疑問，Java，Ruby，Go，C#之類的現代語言比彙編和C之類的老語言有着更好的編碼性能。主要因素是對于一個已知的應用程式，對于可複用的功能，現代語言需要更少的、獨特的代碼。