两周三行代码——这并不总是懒惰（或重新思考我们如何衡量开发者生产力）

Source: Dev.to

（请提供需要翻译的正文内容，我才能为您完成翻译。）

开发者未被看到的工作

我思考这个话题很久，终于决定把它写下来。

整个用代码行数来评估代码，或其他估算工作量的做法，一直让我感到困扰。

我现在不再大规模写代码——也许只为自己写一些小工具，但我过去写了很多代码，已经超过 15 年。

每日舞蹈

早上来到办公室，开始写东西，当然会随时保存。
晚上我有时喜欢按 Ctrl + Z，快进（即使是倒放）地观察光标的移动，代码块被高亮、出现、消失的过程。

• 首先，一个条件和一个循环会出现在同一个位置。
• 然后，循环中的一段代码会移到一个过程里，循环会完全消失，诸如此类。

这是一场光标与其下文字的迷人舞蹈。

到一天结束时，我会得到一个新的简洁过程以及对已有代码块的几次插入——总计 50–80 行代码。
我经常需要完善遗留代码，小心地在不同位置集成我的新增内容而不破坏任何东西。

“谁看见了我所有的搜索和徘徊？”

对外部观察者而言，只能看到早晨的行数和晚上结束时的行数。那 80 行甚至没有暗示我整天都在做什么。我相信你能明白我的意思。

缺失的遥测

在对 AI 充满狂热的时代，我总觉得应该让整个认知过程合法化。

在网站上，追踪用户行为的机制早已被使用：他们点了哪里、在页面上停留了多久、滚动了多远，等等。

为什么在开发中没有类似的东西？

• 在模块之间切换
• 将鼠标悬停在方法上以查看工具提示
• 浏览依赖、搜索、输入文本、选择、删除、移动
• 添加库、修复配置、运行、编译、测试运行、重新编译
• 步进式调试（逐步进入/退出）

所有这些都耗费了大量时间和认知工作。

SQL 调试示例

调试一个复杂的 SQL 查询可能需要一周时间：

1. 查看执行计划，测量 I/O 统计信息，添加索引。
2. 拆分子查询的片段，分别调试，然后再把它们插回去。

谁能看到这些？没有人。只有你自己。

一周结束时，提交看起来像是三个简短却完美的修复在查询中。你整整一周都在做什么？只是在添加那三行代码吗？有时你会感到不安，意识到你的工作成果在外部观察者眼中是怎样的。

开发工作的现实

每个人都习惯于评估 结果，但在开发中——就像在科学中一样——90 % 的时间是实验和寻找错误。评估工具是为结果而设计的，就好像你要从现在一直挖到午饭时间。

没有人会欣赏你所有的挣扎、试验和错误，但正是这些孕育了结果。

如果遥测将你所有的操作收集到日志中，然后绘制出图表，或让 AI 评估其难度，业务方就能看到你工作透明且可证明的全貌。

毕加索的类比

有一个关于毕加索的故事。有人请他在纸巾上画一幅速写。他用了几分钟就完成了。当被问及报酬时，他报了一个巨额的数字。客户大为恼火——“你怎么能只为两分钟的工作要这么多钱？”

毕加索回答说，这并不是用了两分钟，而是用了他的整个生命。

这难道不让开发者产生共鸣吗？他们在看不见的工作上花费了大量时间，却要向客户证明这并非仅仅是两行代码？

一个提议的解决方案：开发遥测

我们可以收集成千上万条真实的开发过程日志（以及模仿日志），并在其上训练模型以识别模式。

• 原始日志不适合直接用于训练，但我们可以从中构建 heat maps 或 activity graphs。
• 该图将展示过程的“脉搏”。有人工作更快，有人更慢，但整体流程大致相似。

实现思路

1. 外部工具，仅负责记录工作。
2. 在设置中，用户定义 要收集的具体内容 以及来源的应用程序（IDE、调试器、SQL 编辑器、Postman、浏览器等）。
3. 使用正则表达式的标题过滤、对象类型过滤等。
4. 日志示例：从调试器切换到 SSMS/PL/SQL，长时间纠结后，再跳转到 Stack Overflow 并浏览数十页内容。

其结果将是 带上下文的增量操作记录，而不仅仅是结果的差值。这不是用于监控，而是用于分析 我们（人类）到底是如何完成工作的，因为这才是最有趣的部分。

人类的过程：孵化与洞察

众所周知，一个人不可能从 9 点写代码到 6 点，尤其是当需要寻找解决方案，而不仅仅是敲出标准算法时。

• 有时你根本无法清晰思考。
• 你可以强迫自己写下所有想写的东西——这没有帮助；你会产生一堆以后自己都看不懂的凌乱代码。

解决方案就在舌尖上。你感觉它存在且很简单，但却没有形成清晰的画面。你已经尝试了数十种方案，但完美的结果仍未出现。

你需要一个 分心——阅读笑话、新闻、观看猫咪视频——让你的思绪 重新组织。这就是 孵化，它可能持续几小时到数天。

某个时刻灵感突现——解决方案恍然大悟。你打开代码，看到自己写的东西，心想：“我的天，这是什么？！” 删除它！然后在五分钟内写出一个立刻可用的代码块，而这在之前的几天里根本无法实现。

---

结束语

如果我们能够捕捉开发者工作 完整、细致的全过程——不仅仅是最终的代码行数——我们就能拥有一种更丰富、更公平的方式来评估工作量、改进工具，甚至教会 AI 更好地理解软件背后的创作过程。那些看不见的工作值得被看到。

热图洞察认知工作流

最初发表于 Habr（俄语）。

在对自己感到尴尬时：我花了这么多时间，但如果有人问，根本没有东西可以展示。这是认知失调。我们习惯用体量来衡量。如果某件事值得做，就应该有很多，对吧？

你怎么向业务解释，为什么你在两周时间里有一周在看视频？

这样的阶段——孵化‑洞察——在热图上是可见的，因为它之前是一段强度极高的试错过程，你一次又一次地重写同一段代码，然后在 IDE 中停顿，浏览器里看猫，最后出现一个简短的最终方案。

可能会出现隐私顾虑。但个人可以自行决定记录什么、不记录什么，这符合他们的利益。关键是，日志不一定要包含文本；它们可以只包含标记，基于这些标记就可以构建热图。搜索阶段到底写了什么、质量如何并不重要；尝试次数和选项数量才更关键，因为所有时间都花在了这些上。

有效的管理者可能会利用这一点对付你。毕竟，佩佳（Petya）一直在挣扎，最终产出了一堆怪物代码，而瓦西亚（Vasya）去看猫，回来后只写了三行完美的代码。但这正是需要这种热图统计和 AI 公正性的地方。类似于神经网络分析透视影像时，即使经验丰富的专家看不出特别之处，神经网络却能捕捉到标记。

为什么现在还没有这种工具？

举个学校数学题的例子，求一个田地的面积。

在学校里，他们教如何使用勾股定理。他们会反复练习几十道题，让学生从不同角度接触同一个定理。等到材料被吸收后，就进入新主题。但在学校里，教的是已经经过数百年演变成手册的成套流程。

而在工作中，个人常常被迫独立构建自己的流程。是的，基于学校里学到的，但必须自行实现。

也许这些热图可以在科学研究中找到应用，或者它们可以取代面试中的笔试（不再让候选人解题或做 IQ 测试，而是展示一张“思维风格护照”，因为这才是招聘时大家真正追求的，而不仅仅是算法知识）……

你怎么看？