写点什么

在软件开发中应用 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:472786
用户头像

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

关注

评论

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

利用混沌工程提高微服务的弹性

NGINX开源社区

nginx 微服务架构 性能 企业号 2 月 PK 榜

尚硅谷发布九章云台项目视频

小谷哥

点对点传输现状,镭速高速点对点传输解决方案

镭速

启科量子解决方案实践:使用QuTrunk+AWS Deep Learning AMI(TensorFlow2)构建量子神经网络

启科量子开发者官方号

人工智能 量子计算

下一朵云,会是谁

ToB行业头条

前端线下面授培训机构的选择

小谷哥

速剖架构(一)-- 流量的自然走向

Dinfan

架构设计

NFT铸造系统模式开发定制

开发微hkkf5566

程序员必备的数据库知识 2:Join 算法

NineData

数据库 程序员 join SQL sever NineData

单体应用、SOA、微服务,优劣势都有哪些?

FinFish

微服务 微服务架构 前端开发 移动开发 小程序化

Go1.20新版本正式发布,新特性值得一看

王中阳Go

Go golang 高效工作 学习方法

RocketMQ 监控告警:生产环境如何快速通过监控预警发现堆积、收发失败等问题?

阿里巴巴云原生

阿里云 RocketMQ 云原生

设计模式-工厂方法模式和抽象工厂模式

C++后台开发

数据结构 设计模式 后端开发 Linux服务器开发 C++开发

干货分享 | 3个Zbrush实用减面工具分享

3DCAT实时渲染

3D渲染 3D模型

UE干货| UE虚幻引擎调试神器—控件反射器

3DCAT实时渲染

游戏开发 虚幻引擎 ue 游戏开发引擎

《流浪地球2》“数字生命”最后一秒拯救人类,现实中AI也正在“长出”灵魂

硬科技星球

真正的低代码平台

陈飞

PaaS SaaS 低代码平台

前端报表如何实现无预览打印解决方案或静默打印

葡萄城技术团队

新书上市 | 以过去预测未来,有趣的时间序列

图灵教育

机器学习 统计学 时间序列 时间序列预测

BIGO 如何做到夜间同时运行 2.4K 个工作流实例?

Apache DolphinScheduler

spark 工作流调度 Apache DolphinScheduler 离线计算

巧用Maya轴心操作小技巧,工作事半功倍!

3DCAT实时渲染

Maya,渲染 Autodesk Maya

干货分享 | UE游戏鼠标双击判定

3DCAT实时渲染

游戏开发 虚幻引擎 ue 游戏开发引擎

上海前端培训学习的就业前景

小谷哥

浅谈 2022 前端工作流中全流程多层次的四款测试工具

Liam

前端 测试 前端开发 测试工具 测试开发

怎么正确使用 NPS ?用对了才事半功倍

鼎道智联

运营 用户体验 用户推荐

大数据培训学习怎么入门

小谷哥

基于流量双发平台的高效回归方案

网易云信

反垃圾 业务集群

化繁为简|中信建投基于StarRocks构建统一查询服务平台

StarRocks

数据库 大数据 开源

前端技术培训学习哪个机构好?

小谷哥

新书上市 | 以过去预测未来,有趣的时间序列

图灵社区

机器学习 统计学 时间序列 时间序列预测

Apache RocketMQ 入选 SegmentFault 年度中国技术品牌影响力企业榜单!

阿里巴巴云原生

阿里云 Apache RocketMQ

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