-2000 行代码（2007）

原文 ↗ Hacker News 讨论 ↗

LOC 作为 KPI 与古德哈特定律

  • 普遍认为把代码行数（LOC/KLoC）作为绩效指标是有害的：它会奖励冗长、重复和复杂性。
  • 这被视为古德哈特定律的教科书式案例：一旦 LOC 成为目标，开发者就会优化“更多代码”，而不是“更好的代码”。
  • 有人指出，即使不是正式 KPI，LOC 也同样具有误导性；如果管理者隐含地更看重“更多代码”，它仍会塑造激励。

LOC 实际能说明什么（如果有的话）

  • 有人认为，LOC 和提交量可以作为众多信号中的一个弱信号：如果某人在几个月里一直是极少、看起来很琐碎的提交，可能是在卡住或表现不佳。
  • 也有人反驳说，每一个有意义的情况（棘手的 bug、架构工作、带人、避免不必要功能）都会打破这种相关性，所以 LOC 除了直接审查工作和结果之外，没有独特价值。
  • 有人建议用 ΔSLOC（新增 + 删除）作为“变化”的稍好代理，但对“生产力”来说仍然很差。

负 LOC 与代码作为负债

  • 许多人会为删除大量代码、或用少量清晰函数替换数千行代码而感到高兴，认为这是高价值工作。
  • 代码被反复描述为成本或负债；资产是功能本身。最好的代码往往就是没写出来的代码。
  • 几个轶事：巨大的重复代码块被收拢成小的可复用函数；大型快照测试或样板代码被移除；长期存在的 bug 通过很小的改动被修复。

管理、流程与文化

  • 对依赖简单、浅层指标（LOC、“影响力发布”）而不是理解工作的管理方式，批评很强烈。
  • 好的管理被描述为：技术上胜任、会读代码、帮助排除阻塞、保护工程师，并从多维度看待生产力。
  • 每日站会存在争议：有人觉得它有助于协调；也有人把它看作“货物崇拜”式的状态仪式，应该被更好的协作和代码审查所取代。

权力、工会与手工艺式软件

  • 这个故事强调，只有高地位的人才能公开无视糟糕的指标；其他人则可能面临惩罚。
  • 有人提议通过工会来防止绩效指标被报复性使用，不过工会的缺点和政治因素也被承认。
  • 有些人感叹大型企业环境挤压掉了“手工艺”式的软件工艺，而另一些人则指出它在开源和小型初创公司中仍然兴盛。

AI 与代码体量

  • 参与者把 LOC 讨论与 AI 代码生成联系起来：那些能廉价生成大量平庸代码的工具，可能会加剧“代码越多 = 价值越大”的谬误，而不是修正它。