Firefox mysql 程序员 centos Python 编程 微软 nginx google Ubuntu linux Android wordpress 云计算 开源 java shell apache Windows php

在軟件開發中應用80:20原則

Jim Bird 是一位經驗豐富的軟件開發經理、項目經理與 CTO,專註於軟件開發與維護中疑難問題的解決、軟件質量管理與安全領域。在過去的 15 年間,Jim 曾管理過團隊建設與高性能的財務系統。他的主要興趣在於如何幫助小團隊更有效地構建真正的軟件:高質量、安全、高性能且易使用。近日,Jim 撰文談到了如何在軟件開發中應用流行的80:20 原則,頗具代表意義。

  很多經理都不想陷入太多的思考當中,他們喜歡簡單的原則,快速且直接的審視問題的方式並能找準問題的方向。越簡單,越好。其中最為有效的一個原則就是80:20 原則:

80% 的效果是由 20% 的原因導致的,或者是 80% 的結果來自於 20% 的努力。
  這是收益遞減的另一方面:相對於做得越多,得到越少來說,你可以實現做得少但得到多的結果,方式就是通過更加聰明而非更加努力的工作。

  不用太費力你就能發現在軟件開發中 80:20 原則的用武之地。比如說,80% 的性能改進是通過優化 20% 的代碼實現的,雖然在性能優化這個領域實際的比率可能更加接近於 90:10,甚至是 99:1。不過,無論是 80:20、90:10 還是 70:30,這個原則本質上沒什麼差別。

  80:20,誰使用什麼,你需要交付的到底是什麼

  在軟件開發中,另一個眾所周知的 80:20 原則就是 80% 的用戶只使用了 20% 的特性。這來自於 Standish Group 在 2002 年的一項研究成果,他們發現:

45% 的特性是從來沒有被使用過的
19% 的特性很少為人使用
16% 的特性有時會被使用
只有 20% 的特性是被頻繁使用的
  這個發現對敏捷與精益開發產生了深遠的影響,它鼓勵人們將精力放在最小的特性集或是最小的產品上,即便在大規模的企業項目中亦如此。相對於設計與規劃大量的特性來說,定義重要且有用的特性才是正確之道:定義好特性的優先級,然後以穩健的步伐盡快交付。

  Standish Group 最新的研究成果表明縮小思考範圍,交付更少的特性是促使軟件項目成功的關鍵之所在。有超過 70% 的小項目是成功交付的,而很多大型項目在延遲交付、預算超支以及漏掉關鍵特性上的可能性要超出小項目的兩倍之多。

  80:20,Bug 與測試

  代碼質量、Bug 與測試是另一個適用於 80:20 原則的領域:

80% 的 Bug 是由 20% 的代碼造成的
90% 的停機是由 10%(甚至更少)的缺陷造成的
  Bug 總是集中爆發在某幾部分代碼中,特別是嚴重的 Bug;而大多數嚴重的問題都是由少數幾個 Bug 導致的。

Windows 與 Office 中 80% 的錯誤與崩潰是由檢測出的 20% 的 Bug 造成的。
  理解大多數嚴重的 Bug 發生在何處,為什麼會在那裏,該如何去做才能防止這些 Bug 的產生,你應該將時間花在這方面。還有些研究發現你所編寫的一半代碼是沒有 Bug 的,而大多數 Bug 都出現在 10—20% 的代碼中間,通常來說,這 10—20% 的代碼是經常被改動的代碼。每次發現代碼中的 Bug 時就表明還有更多 Bug 需要修復。你發現的 Bug 越多,剩下的 Bug 也就越多,這是一種惡性循環。每次碰到那些高風險代碼時,甚至在你嘗試修復一些問題時,那麼很有可能你會將事情搞得越來越糟而不是越來越好:當開發者修復 容易出錯的代碼中的一個 Bug 時,有 20% 的機會他會引入新的 Bug,即所謂的副作用。

  大多數容易出錯的模塊都是非常復雜的,也是很難理解的,因此也是難以修復的。有些 Bug 要比其他 Bug 更難以修復。有時是因為代碼質量很差、有時是因為問題難以重現和調試、有時是因為他們隱藏得更深。

  80:20,哪些代碼被修改了,修改頻率是多少

  Michael Feathers 發現 80:20 原則也適用於代碼隨時間變化的頻率:

80% 的修改發生在 20% 的代碼上
  很多代碼一旦寫完之後就再也不會被修改了,比如說靜態與標準化的接口、基本的配置等等。還有些代碼一直都在發生著變化:20% 的特性花了 80% 的時間,他們經常會根據需求的變化而發生變化;需要不斷優化的核心代碼、還有些代碼會經常發生變化是因為出現了太多的 Bug。

  向已有的方法添加代碼要比添加新方法容易,向已有的類添加新方法要比添加新的類容易。

  這樣,很多系統最後都會有幾個非常龐大的類,包含了大量的方法,隨著代碼的不斷變更,這些類將會變得越來越大。

  80:20 與編程時間

  前 80% 的代碼只花了 20% 的時間,而剩下的 20% 的代碼則花了其余的 80% 的時間。完成某個功能通常並不會花太多時間,特別是采用疊代與漸進的方式、頻繁且快速的交付的情況下。

  不過在背後通常還會有大量工作等待你去完成,比如說處理邊界情況、處理錯誤,確保系統的性能與可伸縮性,尋找並修復各種 Bug,部署前的各種調整等等。客戶通常並不理解為什麼最後的 20% 工作要花費那麼多的時間。程序員也經常忘記這一點,因此在估算時就會發生各種偏差。這也是開發者經常出現估算錯誤的原因所在。

  80:20 與軟件開發管理

  時刻謹記 80:20 原則可以節省你大量的金錢與時間,將精力專註於重要的事情上可以不斷提升你成功的可能性。哪些事情是重要的呢?比如說重要的特性、大多數嚴重的 Bug 出現的代碼區域(需要花費最多時間去修復的 Bug),經常會發生變化的代碼。你與你的團隊應該將註意力放在這些地方上才能確保最後的成功。

延伸阅读

    评论