衡量开发者生产力 » 代码简洁性

代码简洁性

衡量开发者生产力

2017年1月3日 by Max Kanat-Alexander

自从我开始致力于改善软件工程师的生活以来，人们就一直问我如何衡量开发者的生产力。我们如何判断存在生产力问题？如何知道团队随时间推移是变好还是变差？经理如何向高级经理解释开发者的生产力？等等。

总的来说，我倾向于首先关注代码简洁性，而对衡量开发者所做的每一件事给予较低的优先级。几乎所有的软件问题都可以追溯到未能应用软件工程原则和实践。因此，即使没有测量，如果你只是在整个公司应用良好的软件工程实践，大多数生产力问题和开发问题都会消失。

话虽如此，衡量事物具有巨大的价值。它帮助你 pinpoint 困难领域，允许你奖励那些生产力提高的人，证明在必要时花更多时间在开发者生产力工作上，并具有许多其他优势。

但编程不同于其他职业。你不能像衡量某些制造过程那样衡量它，在那里你只需计算从装配线上滚下的正确制造的物品数量。

那么，你将如何衡量程序员的产出呢？

“生产力”的定义

秘密在于适当地定义“生产力”这个词。许多人说他们想“衡量生产力”，但从未思考过生产力实际上是什么。如果你甚至没有定义它，你怎么能衡量某物呢？

理解生产力的关键是意识到它与产品有关。一个生产力高的人是定期且高效地生产产品的人。衡量开发者生产力的方法是衡量他们生产的产品。

仅凭这一陈述可能不足以解决问题。因此，让我给你一些你不会衡量的东西的例子，然后是一些你会衡量的东西，以给你一个总体概念。

为什么不“代码行数”？

软件行业试图开发的最常见指标可能集中在开发者编写了多少行代码（缩写为 LoC）。我理解为什么人们尝试这样做——它似乎是你可以衡量的东西，那么为什么不跟踪它呢？编写更多代码的程序员更有生产力，对吧？

嗯，不是。这里的部分诀窍是：“计算机程序员”实际上不是一份工作。

等等，什么？但我到处看到“程序员”作为工作的广告！嗯，是的，但你也到处看到“木匠”的广告。但“一个木匠”生产什么？除非你更具体，否则很难说。你可能会说木匠制作“切割的木块”，但那不是产品——没有人会雇你无意义地切割或塑造木块。那么“一个木匠”可以做什么工作呢？嗯，工作可能是家具维修，或建造房屋，或制作桌子。在每种情况下，木匠的产品都不同。如果他是家具修理工（一份有效的工作），那么你会衡量他修好了多少家具。如果他在建造房屋，你可能会衡量他完成了多少个没有任何木工缺陷的房间。

这里的重点是“计算机程序员”，就像“木匠”一样，是一种技能，而不是一份工作。如果你想知道一个人生产了多少，你不会衡量技能的实践。你衡量该技能生产的产品的一些方面。为了说明这一点，将其推向荒谬的程度——如今计算机编程技能的一部分涉及在键盘上打字，但你会通过他们每天在键盘上敲击多少键来衡量程序员的生产力吗？显然不会。

衡量代码行数比衡量键盘敲击键数不那么荒谬，因为它确实似乎是程序员生产的东西之一——一行代码似乎是一个可以交付的成品，即使它很小。但它本身真的是一个产品吗？如果我估计一项工作需要 1000 行代码，并且我要为此收费 1000 美元，如果我只交付一行代码，我的客户会付我 1 美元吗？不，我的客户不会付我任何钱，因为我根本没有交付任何产品。

那么，你将如何在现实世界中应用这一原则来正确衡量程序员的产出呢？

确定一个有效的指标

首先要弄清楚的是：程序为其用户产生什么有价值的东西？通常通过快速查看软件的目的来回答这个问题——确定你正在帮助哪群人用你的软件做什么，并弄清楚你如何将该帮助的结果描述为一个产品。例如，如果你有会计软件帮助个人报税，你可能会衡量使用你的软件完全且正确提交的纳税申报表总数。是的，其他人也对此有贡献（如销售人员），但程序员对实际工作如何轻松和成功地完成负主要责任。人们可能希望选择密切关 only 程序员可以控制的事情的指标，但不要在这方面过头——程序员不必是唯一可能影响指标的人，以便它成为他们个人产出的有效衡量。

对于一个系统，可能有多件事要衡量。假设你正在开发一个购物网站。该网站的后端开发人员可能会衡量成功填充的数据请求数量，而网站购物车的前端开发人员可能会衡量成功放入购物车的商品数量，每天成功完成结账流程的人数等。

当然，人们还会确保任何提议的指标也与整个系统的整体指标一致。例如，如果后端开发人员只衡量“在后端接收的数据请求数量”，但不关心它们是否被正确填充、填充速度如何，或其他什么，他们可能设计一个需要太多调用的糟糕 API，这实际上损害了整体用户体验。因此，你必须确保你正在查看的任何指标，你都将其与帮助实际用户的现实进行比较。在这种特定情况下，更好的解决方案可能是计算，比如说，有多少“提交支付”请求被正确处理，因为那是最终结果。（顺便说一句，我不会将其作为购物网站后端的唯一可能指标——那只是一个可能的想法。）

当你的产品是代码时怎么办？

有些人交付代码作为他们的产品。例如，库开发者的产品是代码。但它很少是单行代码——它更像是一个完整的函数、类或一组类。对于库开发者，你可能会衡量诸如“发布供程序员使用的完全测试的公共 API 函数数量”之类的东西。在这种情况下，你可能还必须做一些事情来计算现有函数的新功能，比如将每个改进其 API 的函数的新功能计算为一个全新的交付“函数”。当然，由于原始指标说“完全测试”，任何新功能也必须完全测试才能计数。但无论你选择如何衡量，这里的重点是，即使对于产品是代码的少数人，你也在衡量产品。

从事开发者生产力工作的人怎么办？

这确实留下了最后一类，即从事提高开发者生产力工作的人。如果你的工作是帮助其他开发者更快地移动，你如何衡量这一点？

嗯，首先，大多数从事开发者生产力工作的人确实有一些特定的产品。要么他们从事测试框架（你会以类似于衡量库的方式衡量），要么他们从事开发者使用的某些工具，在这种情况下，你会衡量该工具的成功或使用情况。例如，bug 跟踪系统的开发者可能想衡量成功且快速解决的 bug 数量。当然，你会修改这一点以考虑工具在公司中的使用方式——也许 bug 跟踪器中的某些条目 intended 长期存在，因此你会以其他方式衡量这些条目。总的来说，你会问：我们通过从事这个工具工作给世界带来了什么产品或结果？那就是你要衡量的。

但如果你不从事某些特定的框架或工具呢？在这种情况下，也许你的产品与软件工程师 themselves 有关。也许你会衡量工程师被你的工作协助的次数。或者你的更改节省的工程时间量，如果你能可靠地衡量这一点（这很少可能）。但总的来说，这项工作可能比其他类型的编程更难衡量。

我过去提出的一件事（虽然尚未实际尝试）是，如果你有一个帮助特定团队提高生产力的人，衡量这些团队随时间经历的生产力改进。或者也许衡量团队指标改进的速度。

例如，假设我们纯粹根据产品带来多少收入来衡量一个产品。（注意：纯粹通过这个指标来衡量产品是罕见的——这是一个 artificial 例子来演示这一切如何工作。）假设第一周产品带来了 100 美元。下周 101 美元，再下周 102 美元。那是增加，所以还不错，但不是很令人兴奋。然后玛丽来帮助团队提高生产力。产品那周赚了 150 美元，然后 200 美元，然后 350 美元，随着玛丽继续工作。它从每周增加 1 美元的速度增加到每周增加 50 美元，然后 100 美元，然后 150 美元的速度。这对玛丽来说似乎是一个有效的衡量。当然，可能有其他因素 contribute 该指标的改进，所以它不完美，但如果你真的有一个“纯粹”的生产力开发者，它比没有好。

结论

关于如何衡量员工、团队和公司的产出，还有很多其他要知道的事情。以上观点仅旨在讨论如何对待一个程序员并找出你应该衡量的一般事物。关于进行测量的正确方式、如何解释这些测量以及如何选择不糟糕的指标，还有更多要知道。但希望以上内容能让你开始解决如何衡量个体程序员、团队和整个软件组织的产出的巨大谜团。

-Max

分享 点击在 Facebook 上分享（在新窗口中打开） Facebook 点击在 LinkedIn 上分享（在新窗口中打开） LinkedIn 点击在 Hacker News 上分享（在新窗口中打开） Hacker News 点击在 Reddit 上分享（在新窗口中打开） Reddit 点击在 Threads 上分享（在新窗口中打开） Threads 点击在 X 上分享（在新窗口中打开） X

14 条评论 留下回复

Shailesh 说：2017年1月5日晚上10:20 这是一篇不错的博客，作为软件开发人员，我可以跟踪自己的日常发展，以变得更有生产力。感谢写作。 回复

divp 说：2017年3月22日凌晨1:11 伟大的博客…我将定义更多方式 这个是给定一段未知代码用程序员理解的语言，和一个错误报告，他们能多快理解错误的来源并修复它。 一个人能多快调试问题以及程序员能多好地以专注的方式工作于任务，通过这个我们可以判断开发者生产力…虽然好文章感谢分享 回复

Kyle 说：2017年6月3日上午11:16 好文章！你在文章中回避了一个关键点，即生产力只有在最终结果产生价值时才重要。换句话说，如果构建的东西没有用并且没有为目标受众提供价值，那么某人的生产力如何并不重要。 我启动了 https://www.codemonkey.ai 通过连接到整个软件开发工具链并基于他们完成的工作项（来自问题跟踪系统的功能和错误）通过提交（源代码控制）以及这些更改对用户的影响（应用程序性能管理/日志记录）来衡量开发者的生产力。 回复

Max Kanat-Alexander 说：2017年7月26日晚上9:43 是的，关于价值的一点实际上在我的书中。 -Max 回复

Cara 说：2017年6月12日上午8:18 真正的好文章。确定一个有效的指标对我们公司来说一直是最困难的部分，因为我们从事许多不同类型的项目（并且通常与可能影响某些指标的各种合作伙伴合作）。 回复

10篇非凡的时间管理和生产力文章，2016年8月1日 - TimeCamp 说：2017年6月15日晚上9:06 […] 代码简洁性 – 衡量开发者生产力 – 由 Max […] 回复

Tom Hombergs 说：2017年6月22日上午10:53 好文章。让我开始思考… 我知道你描述的指标只是例子，但当你查看有多少商品成功放入购物车或有多少人无误地完成结账流程时，你真的在衡量生产力吗？那更像是衡量产品的质量或成功，而不是团队定期且高效地生产产品（或产品增量）的方式。 不要误解我：我完全同意团队应该通过这样的成功指标来衡量！团队甚至可能应该通过提供激励如游戏化机制或直接奖金来激励实现良好的成功指标。 但为了衡量生产力，我宁愿回退到诸如“每周投入生产的功能数量”或“每周修复的错误数量”等指标。并且为了激励团队使这些功能和错误修复高质量（而不是仅仅快速和肮脏只是为了有生产力），我会将它们与成功指标如“低错误率”或“成功完成的业务交易”如那些结账结合起来。 然而，我还不知道如何在特定项目中实现这种生产力和成功指标的组合。我会再思考一下… :)。有人有想法吗？ 回复

Max Kanat-Alexander 说：2017年7月26日晚上9:49 “每周投入生产的功能数量”和“每周修复的错误数量”都是传统的指标，已经尝试了几十年，并因各种原因失败。 如果你查找“功能点”，你会发现为试图量化“功能”而设计的最复杂的系统。它如此复杂，以至于没有人能可靠地实际做到，使其成为一个糟糕的指标。不太复杂的系统失败是因为“一个功能”不是一个明确定义的对象，并且“功能”都有不同的大小。 衡量修复的错误数量是有问题的，因为人们跟踪不好，不同的错误有不同的大小，一些错误修复对用户比其他更有价值，有时做功能工作更有价值，人们游戏指标等。可能有理由跟踪未解决问题的数量和处理速度，但它不应该用于衡量开发者生产力。 如果你真的想知道生产力，你必须定义这个词本身并衡量它，经过多年的广泛搜索，你最终会得到我上面写的博客文章。我猜在我和其他人之间，我已经 involved 在这个问题上花费了数百人年，而我上面写的是我知道的最佳解决方案。 -Max 回复

Steven Gordon 说：2017年8月4日上午8:47 你会用这样的指标做什么？从任何目标开始，我相信我能找到比虚假生产力指标更接近实现该目标的东西。 回复

Saim Aksr 说：2017年10月19日下午5:33 感谢写作如此好的信息性文章，我是网站开发者，最大生产力是我的日常目标 🙂 回复

联邦网络攻击、Dropbox 安全等… - Intertech 博客 说：2018年7月12日上午7:57 […] 衡量开发者生产力是出了名的困难。一些关于 thoughtful 衡量的想法。 […] 回复

Enola Labs 说：2018年10月3日下午12:17 非常有见地且跳出框框的思考生产力的方式。 回复

衡量生产力 – 2018年秋季软件发现 说：2018年10月19日下午12:40 […] 进一步研究答案，我阅读了经验丰富的开发者 Max Kanat-Alexander 的“衡量开发者生产力”。在这篇博客文章中，他从什么是 […] 的根源开始 回复

代码的价值 - SoatDev IT 咨询 说：2023年7月13日上午11:14 […] 依赖代码贡献的风险通常是众所周知的，尽管 LOC 和贡献测量是周期性流行的。它可能导致： […] 回复

留下回复取消回复

联系 关于 书：理解软件 书：代码简洁性

输入你的邮箱… 订阅

© 2025 版权所有。由 The Fox 提供支持。

管理同意 为了提供最佳体验，我们使用 cookies 等技术来存储和/或访问设备信息。同意这些技术将允许我们处理数据，如浏览行为或本网站上的唯一 ID。不同意或撤回同意，可能会 adversely 影响某些特性和功能。

功能 功能 始终活动 技术存储或访问严格 necessary 用于合法目的，即启用订阅者或用户明确请求的特定服务的使用，或 solely 用于通过电子通信网络进行通信传输。

偏好 偏好 技术存储或访问 necessary 用于存储未由订阅者或用户请求的偏好的合法目的。

统计 统计 技术存储或访问 exclusively 用于统计目的。技术存储或访问 exclusively 用于匿名统计目的。没有 subpoena、互联网服务提供商的自愿 compliance 或来自第三方的额外记录，仅用于此目的存储或检索的信息通常不能用于识别你。

营销 营销 技术存储或访问 required 创建用户配置文件以发送广告，或跟踪用户在网站上或跨多个网站用于类似营销目的。

管理选项 管理服务 管理 {vendor_count} 供应商 阅读更多关于这些目的 接受 拒绝 查看偏好 保存偏好 查看偏好 {title} {title} {title}管理同意联系 关于 书：理解软件 书：代码简洁性

转到顶部