AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

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

  • 2013-11-19
  • 本文字数:2018 字

    阅读完需:约 7 分钟

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),经常会发生变化的代码。你与你的团队应该将注意力放在这些地方上才能确保最后的成功。

2013-11-19 09:472866
用户头像

发布了 88 篇内容, 共 266.8 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营第1周_学习总结

方舟勇士

课程总结

【话题讨论】「世界上最好的语言」?25周岁的 PHP “配” “不配”

InfoQ写作社区官方

php 写作平台 PHP25周年 热门活动

Week01 学习笔记

任小龙

干货|微服务线上生命周期管理

博文视点Broadview

容器 微服务 架构师

架构师训练营-第一周学习总结

hellohuan

极客大学架构师训练营

基于UML的食堂就餐卡系统设计

王海

极客大学架构师训练营

架构师训练营第1周作业一:食堂就餐卡系统设计

sunpengjian

第一周课后作业——食堂就餐卡系统概要设计

jiangnanage

《Web全栈实用编程》一书征集意见

老魚

程序员 大前端 Web 后端 全栈

极客大学架构师训练营第一周学习总结

竹森先生

学习 架构设计 极客大学架构师训练营

架构师训练营-作业2-学习总结

狂奔嘀兔纸

极客大学架构师训练营

从软件架构说起

傻傻的帅

架构 架构要素 架构设计原则

谈谈阿里云发布新一代容器、Serverless 等云原生产品

关贺宇

阿里云 容器 云原生 中间件

食堂就餐卡系统架构设计

任小龙

极客时间 - 架构师训练营 - week1 - 食堂就餐卡系统设计

毛聪

极客时间 极客大学架构师训练营 食堂就餐卡系统设计

产品路线图–您的产品战略路径指南

涛哥 数字产品和业务架构

敏捷 产品经理

我们需要干货吗?

Neco.W

能力提升 经验分享 干货

ZooKeeper核心原理及应用场景

奈学教育

zookeeper

食堂就餐卡系统设计

hellohuan

架构 极客大学架构师训练营

ZooKeeper核心原理及应用场景

古月木易

区块链技术如何应用于版权保护?

CECBC

区块链技术 维权 著作权 版权保护 侵权

ChaosBlade:从零开始的混沌工程(二)

郭旭东

云原生 混沌工程

食堂就餐卡系统架构设计文档

hifly

极客大学架构师训练营 UML 架构文档 部署图 时序图

架构训练营第一周学习总结

陈靓-哲露

架构师训练营-第一周-食堂就餐卡系统设计

Anrika

架构师 极客大学架构师训练营

week1-食堂就餐卡系统设计

不在调上

程序员为什么技术这么厉害,赚得钱却不多?

金刚小书童

程序员 职业规划 技术管理

IT自由职业者是怎么样的感受和体验

古月木易

IT职场

架构师训练营第一周-食堂就餐卡系统设计

王铭铭

架构师训练营第1周作业二:学习总结

sunpengjian

设计模式之单件模式

公众号:程序猿成神之路

Java 设计模式

在软件开发中应用80:20原则_技术管理_张龙_InfoQ精选文章