写点什么

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

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

关注

评论

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

IDC报告:安擎AI服务器同比增长29.2%,三行业位居第一

科技热闻

标星90K,这份Leetcode刷题手册在GitHub爆火!完整版开放下载

架构师之道

Java 编程 算法

以前端视角,漫谈「云端」

京东科技开发者

云计算 前端 云技术 企业号 3 月 PK 榜

2023年最新美团、字节、阿里、腾讯 Java 面经,已拿 offer(附面经分享)

采菊东篱下

Java 面试

重现一条简单SQL的优化过程

GreatSQL

MySQL greatsql greatsql社区

下游需求趋势长期向好,高端产品国产替代空间广阔

华秋电子

使用 DataEase 展示服务器运行状态

搞大屏的小北

Linux监控 Linux监控脚本 监控展示 监控大屏

轻松搞懂云成本优化:FinOps,2023年一定要懂的热点趋势!

博文视点Broadview

世界备份日|有“备”而来,才能不为数据安全“蕉绿”

云布道师

存储

「高频必考」Docker&K8S面试题和答案

王中阳Go

Docker 高效工作 学习方法 面试题 Go 语言

电商通用型商品中心设计

京东科技开发者

构架 企业号 3 月 PK 榜 电商中心 SKU 类目

看完这份SpringBoot神级文档,面试真的可以为所欲为

三十而立

Java IT java面试

企业号 4 月 PK 榜,火热开启!

InfoQ写作社区官方

热门活动 企业号 4 月 PK 榜

聚焦「就近」与「轻计算」,阿里云边缘云连续3年领跑!

阿里云视频云

云计算 边缘计算 边缘云

过亿云资源运维管控难?华为云CloudMap带你喝着咖啡做运维

华为云开发者联盟

大数据 后端 华为云 华为云开发者联盟 企业号 3 月 PK 榜

软件测试丨JavaScript脚本注入,完成Selenium 无法做到的那些事

测试人

JavaScript 软件测试 自动化测试 测试开发 selenium

AIGC热门技术岗平均年薪超百万,脉脉林凡认为白领可能先于蓝领失业

科技热闻

机器学习实战系列[一]:工业蒸汽量预测(最新版本下篇)含特征优化模型融合等

汀丶人工智能

数据挖掘 机器学习 数学建模

拯救脂肪肝第一步!以飞桨3D医疗影像分割方案MedicalSeg自主诊断脂肪肝

飞桨PaddlePaddle

深度学习 计算机视觉 语义分割 PaddlePaddle

利用Jackson序列化实现数据脱敏

京东科技开发者

Jackson 数据脱敏 企业号 3 月 PK 榜

【3.24-3.31】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

构建云边端一体的分布式云架构,软硬结合驱动边缘计算创新场景

百度Geek说

人工智能 架构 分布式 边缘计算 企业号 3 月 PK 榜

秒懂算法 | Treap树

TiAmo

数据结构 算法 节点 旋转法

AIGC时代:未来已来

华为云开发者联盟

人工智能 华为云 AIGC 华为云开发者联盟 企业号 3 月 PK 榜

华秋一文带你读懂PCB中的“金手指”设计

华秋电子

MobPush 厂商通道SDK集成指南

MobTech袤博科技

“ChatGPT们”的淘金时代

OneFlow

易观千帆 | 2023年2月证券APP月活跃用户规模盘点

易观分析

金融 证券 经济

阿里内部进阶学习SpringBoot+Vue全栈开发实战文档

三十而立

vivo 手机云服务建设之路-平台产品系列04

vivo互联网技术

系统设计 稳定性 数据安全 用户数据 手机云服务

简述家居物联网体系架构

毛广斌

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