在软件开发中应用80：20原则

谁借莪１个温暖的怀抱￠ 2022-09-18 11:42 121阅读 0赞

本文来源于我在InfoQ中文站原创的文章，原文地址是：[http://www.infoq.com/cn/news/2013/11/80-20-rules-software-dev][http_www.infoq.com_cn_news_2013_11_80-20-rules-software-dev]

[Jim Bird][]是一位经验丰富的软件开发经理、项目经理与CTO，专注于软件开发与维护中疑难问题的解决、软件质量管理与安全领域。在过去的15年间，Jim曾管理过团队建设与高性能的财务系统。他的主要兴趣在于如何帮助小团队更有效地构建真正的软件：高质量、安全、高性能且易使用。近日，Jim[撰文][Link 1]谈到了如何在软件开发中应用流行的[80：20原则][80_20]，颇具代表意义。

很多经理都不想陷入太多的思考当中，他们喜欢简单的原则，快速且直接的审视问题的方式并能找准问题的方向。越简单，越好。其中最为有效的一个原则就是[80：20原则][80_20 1]：

> 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年的一项[研究成果][Link 2]，他们发现：

*  45%的特性是从来没有被使用过的
 *  19%的特性很少为人使用
 *  16%的特性有时会被使用
 *  只有20%的特性是被频繁使用的

这个发现对[敏捷][Link 3]与精益开发产生了深远的影响，它鼓励人们将精力放在[最小的特性集][Link 4]或是最小的产品上，即便在大规模的企业项目中亦如此。相对于设计与规划大量的特性来说，定义重要且有用的特性才是正确之道：[定义好特性的优先级][Link 5]，然后以稳健的步伐尽快交付。

Standish Group最新的研究成果表明缩小思考范围，交付更少的特性是促使软件项目成功的关键之所在。有超过70%的小项目是成功交付的，而很多大型项目在延迟交付、预算超支以及漏掉关键特性上的可能性要超出小项目的两倍之多。

## 80：20，Bug与测试 ##

代码质量、Bug与测试是另一个适用于80：20原则的领域：

*  80%的Bug是由20%的代码造成的
 *  90%的停机是由10%（甚至更少）的缺陷造成的

Bug总是集中爆发在某几部分代码中，特别是严重的Bug；而大多数严重的问题都是由少数几个Bug导致的。

> [Windows与Office中80%的错误与崩溃是由检测出的20%的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。

向已有的方法添加代码要比添加新方法容易，向已有的类添加新方法要比添加新的类容易。

这样，[很多系统最后都会有几个非常庞大的类，包含了大量的方法][Link 6]，随着代码的不断变更，这些类将会变得越来越大。

## 80：20与编程时间 ##

[前80%的代码只花了20%的时间][80_20 2]，而剩下的20%的代码则花了其余的80%的时间。完成某个功能通常并不会花太多时间，特别是采用迭代与渐进的方式、频繁且快速的交付的情况下。

不过在背后通常还会有大量工作等待你去完成，比如说处理边界情况、处理错误，确保系统的性能与可伸缩性，寻找并修复各种Bug，部署前的各种调整等等。客户通常并不理解为什么最后的20%工作要花费那么多的时间。程序员也经常忘记这一点，因此在估算时就会发生各种偏差。这也是开发者经常出现估算错误的原因所在。

## 80：20与软件开发管理 ##

时刻谨记80：20原则可以节省你大量的金钱与时间，将精力专注于重要的事情上可以不断提升你成功的可能性。哪些事情是重要的呢？比如说重要的特性、大多数严重的Bug出现的代码区域（需要花费最多时间去修复的Bug），经常会发生变化的代码。你与你的团队应该将注意力放在这些地方上才能确保最后的成功。

[http_www.infoq.com_cn_news_2013_11_80-20-rules-software-dev]: http://www.infoq.com/cn/news/2013/11/80-20-rules-software-dev
[Jim Bird]: http://www.blogger.com/profile/17371102366836131341
[Link 1]: http://swreflections.blogspot.ca/
[80_20]: http://www.informit.com/articles/article.aspx?p=1984066
[80_20 1]: http://en.wikipedia.org/wiki/Pareto_principle
[Link 2]: http://luuduong.com/blog/archive/2009/03/04/applying-the-quot8020-rulequot-with-the-standish-groups-software-usage.aspx
[Link 3]: http://pragprog.com/magazines/2011-02/way-of-the-agile-warrior
[Link 4]: http://www.jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Phased%20Releases.html
[Link 5]: http://www.romanpichler.com/blog/agile-product-innovation/the-vision-the-product-backlog-and-the-minimal-viable-product/
[Windows_Office_80_20_Bug]: http://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm
[Link 6]: http://michaelfeathers.typepad.com/michael_feathers_blog/2012/12/behavioral-economics-and-code.html
[80_20 2]: http://stackoverflow.com/questions/608748/how-to-avoid-the-80-20-rule-in-software-development