求知若渴，虚心若愚！
居安思危，积极进取！
最近在一次技术评审会上，我听到一位工程师说："这段代码已经成为技术债务了，我们需要重构它。"当我追问为什么时，他回答："因为写得很烂，难以维护。"
这是一个典型的误解。技术债务从来不是代码写得好不好的问题，而是在特定时刻做出的理性决策。把技术债务等同于"烂代码"，就像把信用卡债务等同于"乱花钱"——你完全忽略了债务背后的战略选择。
一、重新定义技术债务
Ward Cunningham 在 1992 年提出"技术债务"这个概念时，他的本意是：为了更快交付价值，有意识地选择了一个不够完美但足够好的技术方案，代价是未来需要额外的工作来改进它。
注意三个关键词：
然而在实践中，我们常常把四种完全不同的东西都叫做"技术债务"：
> "工具本身从来不是问题的答案,理解问题才是。" —— 未署名的架构师
引言：一场永无止境的争论
在技术社区里,关于 API 设计的争论从未停止。REST 的支持者会告诉你:"遵循 RESTful 原则,你的 API 就会优雅、可扩展。" GraphQL 的拥趸则反驳:"单一端点、精确查询、类型安全,这才是现代 API 的未来。"
但如果我告诉你,这场争论本身就是一个错误的问题?
真正的问题不是"应该选择 REST 还是 GraphQL",而是我们为什么需要在两种范式之间做非此即彼的选择?更深层次的问题是:我们是否真正理解了 API 设计背后的本质问题?
REST 的谎言:资源导向的美丽陷阱
REST(Representational State Transfer)在 2000 年由 Roy Fielding 提出时,是一个革命性的概念。它将 Web 服务抽象为"资源"的集合,通过标准的 HTTP 方法(GET、POST、PUT、DELETE)进行操作。听起来很完美,对吧?
在一次技术管理者的闭门会议上，一位 CTO 分享了他们公司的"成功经验"：通过跟踪每个工程师的代码提交量和故事点完成数，他们将团队产出提升了 40%。台下掌声雷动。
三个月后，这家公司的核心产品因为技术债崩溃，两位资深工程师离职，留下一句话："我不想在一个把我当成代码工厂的地方工作。"
这不是个案。在"数据驱动"的大旗下，工程效能度量正在变成一场全行业的自我欺骗。我们用精确的数字掩盖了对复杂性的无知，用短期的增长牺牲了长期的健康。更危险的是，当度量本身成为目标，我们就陷入了古德哈特定律（Goodhart's Law）的经典困境：当一个度量成为目标时，它就不再是一个好的度量。
一、我们在度量什么：从代码行数到 DORA
工程效能度量的演进史，本质上是管理者与工程师之间信息不对称的博弈史。
1.1 原始指标时代：数数字的快乐
早期的度量极其粗暴：