衡量开发者生产力 » 代码简洁性
几乎从我开始致力于改善软件工程师生活的那一刻起，人们就一直在问我如何衡量开发者的生产力。我们如何判断存在生产力问题的地方？如何知道一个团队随着时间的推移是变好还是变差？管理者如何向高级经理解释开发者的生产力水平？诸如此类的问题层出不穷。
总的来说，我倾向于首先关注代码简洁性，而对衡量开发者所做的每一件事给予较低的优先级。几乎所有的软件问题都可以追溯到未能应用软件工程原则和实践的某种失败。因此，即使没有度量，如果你只是让良好的软件工程实践在整个公司得到应用，大多数生产力问题和开发问题都会消失。
话虽如此，衡量事物具有巨大的价值。它帮助你精确定位困难领域，允许你奖励那些生产力提高的人，证明在必要时花更多时间在开发者生产力工作上是合理的，并具有许多其他优势。
但编程不同于其他职业。你不能像衡量某些制造过程那样衡量它，在制造过程中，你只需计算从装配线上滚下的正确制造物品的数量。
那么，你如何衡量程序员的产出呢？
“生产力”的定义
秘密在于恰当地定义“生产力”这个词。许多人说他们想“衡量生产力”，但从未思考过生产力实际上是什么。如果你甚至没有定义某物，你怎么能衡量它呢？
理解生产力的关键在于意识到它与产品有关。一个高效的人是定期且高效地生产产品的人。衡量开发者生产力的方法是衡量他们生产的产品。
然而，仅凭这一说法可能不足以解决问题。因此，让我给你一些你不会衡量的东西的例子，然后再给你一些你会衡量的东西，以给你一个大致的概念。
为什么不衡量“代码行数”？
软件行业试图开发的最常见指标可能集中在开发者编写了多少行代码（缩写为 LoC）。我理解人们为什么尝试这样做——它似乎是你可以衡量的东西，那么为什么不跟踪它呢？编写更多代码的程序员效率更高，对吧？
嗯，不对。这里的部分诀窍是：“计算机程序员”实际上并不是一份工作。
等等，什么？但我到处看到“程序员”作为工作的广告！嗯，是的，但你也到处看到“木匠”的广告。但“木匠”生产什么？除非你更具体，否则很难说。你可能会说木匠制作“切割的木头块”，但那不是产品——没有人会雇你无意义地切割或塑造木头块。那么，“木匠”可以做什么工作呢？嗯，工作可能是家具维修、建造房屋或制作桌子。在每种情况下，木匠的产品都不同。如果他是家具修理工（一份有效的工作），那么你会衡量他修好了多少家具。如果他在建造房屋，你可能会衡量他完成了多少个没有任何木工缺陷的房间。
这里的重点是，“计算机程序员”就像“木匠”一样，是一种技能，而不是一份工作。如果你想知道一个人生产了多少，你不会衡量技能的实践。你衡量该技能产生的产品的某些方面。为了把这个推到荒谬的水平——只是为了说明观点——如今计算机编程技能的一部分涉及在键盘上打字，但你会通过程序员每天在键盘上敲击多少次来衡量他们的生产力吗？显然不会。
衡量代码行数比衡量键盘敲击次数不那么荒谬，因为它确实似乎是程序员生产的东西之一——一行代码似乎是一个可以交付的成品，即使它很小。但它本身真的是产品吗？如果我估计一项工作需要 1000 行代码，并且我要为此收取 1000 美元，如果我只交付一行代码，我的客户会付给我 1 美元吗？不，我的客户不会付给我任何东西，因为我根本没有交付任何产品。
那么，你如何在现实世界中应用这一原则来正确衡量程序员的产出呢？
确定有效的指标
首先要弄清楚的是：程序生产什么对其用户有价值？通常，通过快速查看软件的目的来回答这个问题——确定你正在帮助哪群人用你的软件做什么，并弄清楚如何将这种帮助的结果描述为产品。例如，如果你有会计软件帮助个人报税，你可能会衡量使用你软件的个人完全且正确提交的纳税申报表总数。是的，其他人也为此做出了贡献（比如销售人员），但程序员对实际工作的轻松和成功完成负主要责任。人们可能希望选择紧密关注只有程序员能控制的事情的指标，但不要过分——程序员不必是唯一可能影响指标的人，以便它成为他们个人产出的有效衡量标准。
一个系统可能有多件事需要衡量。假设你正在开发一个购物网站。该网站的后端开发人员可能会衡量成功处理的数据请求数量，而网站购物车的前端开发人员可能会衡量成功放入购物车的商品数量、每天成功完成结账流程的人数等。
当然，人们还会确保任何提议的指标也与整个系统的整体指标一致。例如，如果后端开发人员只衡量“后端接收的数据请求数量”，但不关心它们是否正确处理、处理速度如何等等，他们可能会设计一个需要太多调用的糟糕 API，这实际上损害了整体用户体验。因此，你必须确保你正在查看的任何指标，你都将其与帮助实际用户的现实进行比较。在这种特定情况下，更好的解决方案可能是计算，比如，有多少“提交付款”请求被正确处理，因为那是最终结果。（顺便说一句，我不会将其作为购物网站后端的唯一可能指标——那只是一个可能的想法。）
当你的产品是代码时怎么办？
有些人交付代码作为他们的产品。例如，库开发者的产品是代码。但它很少是单行代码——它更像是整个函数、类或一组类。对于库开发者，你可能会衡量诸如“发布供程序员使用的完全测试的公共 API 函数数量”之类的东西。在这种情况下，你可能还需要做一些事情来计算现有函数的新功能，比如将每个改进其 API 的函数的新功能计算为一个全新的交付“函数”。当然，由于原始指标说“完全测试”，任何新功能也必须完全测试才能计入。但无论你选择如何衡量，这里的重点是，即使对于产品是代码的少数人，你也在衡量产品。
从事开发者生产力工作的人怎么办？
这确实留下了最后一类人，即从事提高开发者生产力工作的人。如果你的工作是帮助其他开发者更快地移动，你如何衡量这一点？
嗯，首先，大多数从事开发者生产力工作的人确实有某种特定的产品。要么他们从事测试框架的工作（你会以类似于衡量库的方式衡量），要么他们从事开发者使用的某些工具的工作，在这种情况下，你会衡量该工具的成功或使用情况。例如，错误跟踪系统的开发者可能想衡量的一件事是成功且快速解决的错误数量。当然，你会修改这一点以考虑工具在公司中的使用方式——也许错误跟踪器中的某些条目 intended 长期存在，因此你会以其他方式衡量这些条目。总的来说，你会问：通过从事这个工具的工作，我们在世界上带来的产品或结果是什么？那就是你要衡量的。
但如果你不从事某些特定框架或工具的工作怎么办？在这种情况下，也许你的产品与软件工程师本身有关。也许你会衡量工程师被你的工作协助的次数。或者你的更改节省的工程时间量，如果你能可靠地衡量的话（这很少可能）。但总的来说，这项工作可能比其他类型的编程更难衡量。
我过去提出过的一件事（虽然尚未实际尝试）是，如果你有一个帮助特定团队提高生产力的人，衡量这些团队随时间经历的生产力改进。或者也许衡量团队指标改进的速度。
例如，假设我们纯粹根据产品带来多少收入来衡量产品。（注意：纯粹通过这个指标衡量产品是罕见的——这是一个人工示例来演示这一切如何工作。）假设第一周产品带来了 100 美元。下周 101 美元，再下周 102 美元。这是一个增长，所以还不错，但也不是那么令人兴奋。然后玛丽来帮助团队提高生产力。产品在那周赚了 150 美元，然后 200 美元，然后 350 美元，因为玛丽继续致力于此。它从每周增加 1 美元的速度变为每周增加 50 美元，然后 100 美元，然后 150 美元。这对玛丽来说似乎是一个有效的衡量标准。当然，可能有其他因素 contribute 到这个指标的改进，所以它并不完美，但如果你真的有一个“纯粹”的生产力开发者，它比没有好。
结论
关于如何衡量员工、团队和公司的产出，还有很多其他事情需要了解。上述观点仅旨在讨论如何对待程序员并找出你应该衡量的一般事物。关于正确进行测量的方法、如何解释这些测量以及如何选择不糟糕的指标，还有更多需要了解。但希望上述内容能让你开始解决如何衡量个体程序员、团队和整个软件组织的产出的巨大谜团。
-马克斯
评论
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 是的，关于价值的一点实际上在我的书中。-马克斯
Cara 说：2017年6月12日上午8:18 真正的好文章。确定一个有效的指标对我们公司来说一直是最困难的部分，因为我们从事许多不同类型的项目（并且通常与可能影响某些指标的各种合作伙伴合作）。
10 Extraordinary Time Management and Productivity Articles, 8/1/16 - TimeCamp 说：2017年6月15日晚上9:06 […] 代码简洁性 – 衡量开发者生产力 – 作者 马克斯 […]
Tom Hombergs 说：2017年6月22日上午10:53 好文章。让我开始思考……我知道你描述的指标只是例子，但当你查看成功放入购物车的商品数量或有多少人无误地完成结账流程时，你真的在衡量生产力吗？这更像是衡量产品的质量或成功，而不是团队定期且高效地生产产品（或产品增量）的方式。别误会：我完全同意团队应该通过这样的成功指标来衡量！团队甚至可能通过提供激励（如游戏化机制或工资上的纯奖金）来激励实现良好的成功指标。但为了衡量生产力，我宁愿回退到“每周投入生产的功能数量”或“每周修复的错误数量”等指标。为了激励团队使这些功能和错误修复高质量（而不是仅仅快速和肮脏只是为了高效），我会将它们与“低错误率”或“成功完成的业务交易”（如那些结账）等成功指标结合起来。然而，我还没有线索如何在一个特定项目中实现这种生产力和成功指标的组合。我会再思考一下…… :)。有人有想法吗？
Max Kanat-Alexander 说：2017年7月26日晚上9:49 “每周投入生产的功能数量”和“每周修复的错误数量”都是传统指标，已经尝试了几十年，并因各种原因失败。如果你查找“功能点”，你会发现为试图度量“功能”而设计的最复杂系统。它如此复杂，以至于没有人能可靠地实际完成，使其成为一个糟糕的指标。不太复杂的系统失败是因为“一个功能”不是一个明确定义的对象，并且“功能”都有不同的大小。衡量修复的错误数量是有问题的，因为人们跟踪不好，不同的错误有不同的大小，一些错误修复对用户比其他人更有价值，有时做功能工作更有价值，人们游戏指标等等。有理由跟踪未解决问题的数量和处理速度，但不应该用它来衡量开发者的生产力。如果你真的想知道生产力，你必须定义这个词本身并衡量它，经过多年的广泛搜索，你最终会得到我上面写的博客文章。我猜，在我和其他人之间，我已经参与了数百人年致力于这个问题，而我上面写的是我知道的最佳解决方案。-马克斯
Steven Gordon 说：2017年8月4日上午8:47 你会用这样的指标做什么？从任何目标开始，我相信我能找到比虚假生产力指标更接近实现该目标的东西。
Saim Aksr 说：2017年10月19日下午5:33 感谢撰写如此好的信息性文章，我是Web开发人员，最大生产力是我的日常目标
Federal Cyberattacks, Dropbox Security, & More… - Intertech Blog 说：2018年7月12日上午7:57 […] 衡量开发者生产力是出了名的困难。关于 thoughtful 测量的一些想法。 […]
Enola Labs 说：2018年10月3日下午12:17 非常有见地且跳出框框的思考生产力的方式。
Measuring Productivity – Fall 2018 Software Discoveries 说：2018年10月19日下午12:40 […] 为了进一步研究答案，我阅读了经验丰富的开发者 Max Kanat-Alexander 的“衡量开发者生产力”。在这篇博客文章中，他从根源开始 […]
The value of code - SoatDev IT Consulting 说：2023年7月13日上午11:14 […] 依赖代码贡献的风险通常是众所周知的，尽管 LOC 和贡献测量周期性地流行。它可能导致： […]
发表回复取消回复
联系 关于 书：理解软件 书：代码简洁性
输入您的电子邮件… 订阅
Max Kanat-Alexander 6月27日 我目前认为，AI代理可以成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。 我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。 简而言之，如果你告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做了错误的事就会失败。 这意味着你的测试和验证工具越好，你从模型得到的输出就越好。这不仅仅是测试数量的问题。它们必须是好的测试，具有智能断言和良好的错误消息。 这也意味着代理成功涉及思考如何将任务分解成可以分别通过自动化测试、linter等客观验证的单个部分。 作为说明，输入的质量也很重要并在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。 阅读更多2310分享
Max Kanat-Alexander 6月4日 技术债务有价值的想法 mostly 是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那根本不对。它几乎立即开始。做正确的事的成本通常是几个小时，也许一天，而你几乎总是立即收回那个时间。也就是说，做对通常花费与做错相同的时间。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省你的实际时间。 偶尔，你的路径中有一些“岩石”如此巨大，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能一次交付一个一天的功能。但那是技术债务决策的极小、极小部分。 这变得更加疯狂，因为如果你在过程中做对一切（你总是重构系统，使其看起来像是被设计来做它现在做的事情），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切变得复合性地更加困难，以至于你生成没有人能移动的“岩石”。复杂性不是某种线性的东西，你以后可以投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的境地，以至于你公司中没有人有时间或专业知识来修复它。 这一切感觉如此无辜：“让我们只是偷工减料，它将帮助我们满足这个截止日期”（一个截止日期通常是虚构的，无论如何，你可以推迟几周而没有后果）。“很难弄清楚如何做对，我们可以推迟吗？”然后砰，很快你发现自己陷入了一个沼泽，一切都很难，而且“我们不知道为什么！” 我留给你最后一件事：当我直接编码我生活的每一天时，我在这方面完全 uncompromising。我基本上无法看坏代码——我必须重构它，否则我不能做这项工作。不知何故，在我整个职业生涯的那部分中，我从未错过一个截止日期。 阅读更多12940分享
Max Kanat-Alexander 5月30日 我估计，我每看到或被告知一万条坏建议，就收到一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、研究或确定什么是真的。相反，它教人们 memorizing 和重复事实，其中大多数不重要、不真实或无用的。 所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们对事物的意见，无论是在报纸、博客文章、论坛还是其他什么， rarely 具有那种价值。 那么，要点是什么？嗯，最好有一些方法在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据可靠地帮助你完成某事吗？它100%的时间有效，还是更少？ 对于许多帖子，你会发现：这些数据根本无助于你做任何事。 阅读更多249分享
Max Kanat-Alexander 5月29日 你对系统所做的任何更改在推出时都会收到某些人的负面反馈。这发生不是因为每次更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者有一些关于新东西“糟糕”的情感争论，但通常他们真的只是对任何更改发生感到不安。这不是什么不寻常的事；它存在于几乎所有人类中的一个因素。人们往往对在一段时间内愿意经历多少变化有一定的 appetite，如果你超出那个，他们会感到不安。 重要的是要认识到人们的反馈何时仅仅是这种“变化厌恶”与关于有价值事物的真实反馈。有几种方法可以判断：
- 变化厌恶通常持续3到10天。如果你在推出更改后的前3到10天内从用户那里得到反馈，并且同样的反馈没有被大量用户提供，值得考虑用户的响应是否只是变化厌恶。
- 变化厌恶反馈通常是情感化的。它可能是侮辱性的。它可能表达为仅仅一个意见（“新菜单的颜色丑陋”） vs 一个事实（“我