Jim Bird是一位經(jīng)驗豐富的軟件開發(fā)經(jīng)理、項目經(jīng)理與CTO，專注于軟件開發(fā)與維護中疑難問題的解決、軟件質(zhì)量管理與安全領(lǐng)域。在過去的15年間，Jim曾管理過團隊建設(shè)與高性能的財務(wù)系統(tǒng)。他的主要興趣在于如何幫助小團隊更有效地構(gòu)建真正的軟件：高質(zhì)量、安全、高性能且易使用。近日，Jim撰文談到了如何在軟件開發(fā)中應(yīng)用流行的80：20原則，頗具代表意義。
很多經(jīng)理都不想陷入太多的思考當中，他們喜歡簡單的原則，快速且直接的審視問題的方式并能找準問題的方向。越簡單，越好。其中最為有效的一個原則就是80：20原則：
80%的效果是由20%的原因?qū)е碌�，或者�?0%的結(jié)果來自于20%的努力。
這是收益遞減的另一方面：相對于做得越多，得到越少來說，你可以實現(xiàn)做得少但得到多的結(jié)果，方式就是通過更加聰明而非更加努力的工作。
不用太費力你就能發(fā)現(xiàn)在軟件開發(fā)中80：20原則的用武之地。比如說，80%的性能改進是通過優(yōu)化20%的代碼實現(xiàn)的，雖然在性能優(yōu)化這個領(lǐng)域?qū)嶋H的比率可能更加接近于90：10，甚至是99：1。不過，無論是80：20、90：10還是70：30，這個原則本質(zhì)上沒什么差別。
80：20，誰使用什么，你需要交付的到底是什么
在軟件開發(fā)中，另一個眾所周知的80：20原則就是80%的用戶只使用了20%的特性。這來自于Standish Group在2002年的一項研究成果，他們發(fā)現(xiàn)：
- 45%的特性是從來沒有被使用過的
- 19%的特性很少為人使用
- 16%的特性有時會被使用
- 只有20%的特性是被頻繁使用的
這個發(fā)現(xiàn)對敏捷與精益開發(fā)產(chǎn)生了深遠的影響，它鼓勵人們將精力放在最小的特性集或是最小的產(chǎn)品上，即便在大規(guī)模的企業(yè)項目中亦如此。相對于設(shè)計與規(guī)劃大量的特性來說，定義重要且有用的特性才是正確之道：定義好特性的優(yōu)先級，然后以穩(wěn)健的步伐盡快交付。
Standish Group最新的研究成果表明縮小思考范圍，交付更少的特性是促使軟件項目成功的關(guān)鍵之所在。有超過70%的小項目是成功交付的，而很多大型項目在延遲交付、預算超支以及漏掉關(guān)鍵特性上的可能性要超出小項目的兩倍之多。
80：20，Bug與測試
代碼質(zhì)量、Bug與測試是另一個適用于80：20原則的領(lǐng)域：
- 80%的Bug是由20%的代碼造成的
- 90%的停機是由10%（甚至更少）的缺陷造成的
Bug總是集中爆發(fā)在某幾部分代碼中，特別是嚴重的Bug；而大多數(shù)嚴重的問題都是由少數(shù)幾個Bug導致的。
Windows與Office中80%的錯誤與崩潰是由檢測出的20%的Bug造成的。
理解大多數(shù)嚴重的Bug發(fā)生在何處，為什么會在那里，該如何去做才能防止這些Bug的產(chǎn)生，你應(yīng)該將時間花在這方面。還有些研究發(fā)現(xiàn)你所編寫的一半代碼是沒有Bug的，而大多數(shù)Bug都出現(xiàn)在10—20%的代碼中間，通常來說，這10—20%的代碼是經(jīng)常被改動的代碼。每次發(fā)現(xiàn)代碼中的Bug時就表明還有更多Bug需要修復。你發(fā)現(xiàn)的Bug越多，剩下的Bug也就越多，這是一種惡性循環(huán)。每次碰到那些高風險代碼時，甚至在你嘗試修復一些問題時，那么很有可能你會將事情搞得越來越糟而不是越來越好：當開發(fā)者修復容易出錯的代碼中的一個Bug時，有20%的機會他會引入新的Bug，即所謂的副作用。
大多數(shù)容易出錯的模塊都是非常復雜的，也是很難理解的，因此也是難以修復的。有些Bug要比其他Bug更難以修復。有時是因為代碼質(zhì)量很差、有時是因為問題難以重現(xiàn)和調(diào)試、有時是因為他們隱藏得更深。
80：20，哪些代碼被修改了，修改頻率是多少
Michael Feathers發(fā)現(xiàn)80：20原則也適用于代碼隨時間變化的頻率：
80%的修改發(fā)生在20%的代碼上
很多代碼一旦寫完之后就再也不會被修改了，比如說靜態(tài)與標準化的接口、基本的配置等等。還有些代碼一直都在發(fā)生著變化：20%的特性花了80%的時間，他們經(jīng)常會根據(jù)需求的變化而發(fā)生變化；需要不斷優(yōu)化的核心代碼、還有些代碼會經(jīng)常發(fā)生變化是因為出現(xiàn)了太多的Bug。
向已有的方法添加代碼要比添加新方法容易，向已有的類添加新方法要比添加新的類容易。
這樣，很多系統(tǒng)最后都會有幾個非常龐大的類，包含了大量的方法，隨著代碼的不斷變更，這些類將會變得越來越大。
80：20與編程時間
前80%的代碼只花了20%的時間，而剩下的20%的代碼則花了其余的80%的時間。完成某個功能通常并不會花太多時間，特別是采用迭代與漸進的方式、頻繁且快速的交付的情況下。
不過在背后通常還會有大量工作等待你去完成，比如說處理邊界情況、處理錯誤，確保系統(tǒng)的性能與可伸縮性，尋找并修復各種Bug，部署前的各種調(diào)整等等。客戶通常并不理解為什么最后的20%工作要花費那么多的時間。程序員也經(jīng)常忘記這一點，因此在估算時就會發(fā)生各種偏差。這也是開發(fā)者經(jīng)常出現(xiàn)估算錯誤的原因所在。
80：20與軟件開發(fā)管理
時刻謹記80：20原則可以節(jié)省你大量的金錢與時間，將精力專注于重要的事情上可以不斷提升你成功的可能性。哪些事情是重要的呢？比如說重要的特性、大多數(shù)嚴重的Bug出現(xiàn)的代碼區(qū)域（需要花費最多時間去修復的Bug），經(jīng)常會發(fā)生變化的代碼。你與你的團隊應(yīng)該將注意力放在這些地方上才能確保最后的成功。