技术债 (Technical Debt)
技术债是指在开发过程中，为了短期内快速交付或修补现有问题，而采取了折中、不完美的设计或实现方式，从而在未来遗留下了额外的重构与维护工作。
核心特征
Source: 2026-06-21-note-程序员的README（来源未公开）
与金融债务类似，技术债也包含“本金”与“利息”：
- 本金 (Principal)：为了快速上线而采取的折中实现或原始代码缺陷，需要未来花时间修复。
- 利息 (Interest)：由于原有的折中方案没有解决，导致后来的新功能开发不得不基于此编写越来越复杂的变通办法（Workarounds）。随着复杂性蔓延和巩固，利息持续增加，容易滋生更多严重的 bug。
管理与取舍
务实的债务态度
Source: 2026-06-21-note-程序员的README（来源未公开）
- 技术债并非完全不能接受。由于团队有严格的截止日期（Deadline）和优先级约束，有时为了业务爆发而暂时忽略重构、增加技术债反而是正确的商业决策。
- 应当在以下场景保持务实：
- 即将被废弃、低风险或很少被触及的边缘代码，不需要进行过度重构。
- 重构的成本不能超过其创造的商业/技术价值。
规则与自动化治理
Source: 2026-06-21-note-Software-Engineering-at-Google--Hyrum-Wright--Tom-Manshreck（来源未公开）
- 降低记忆负担：规则是控制复杂度、维系代码库可维护性的基础。衡量规则多少的标准不是其数量，而是工程师需要强行记住并遵守的规则数量。
- 自动化工具：引入自动化的代码格式化工具、静态分析工具（linter/gofmt）并接入持续集成流水线，能从源头上拦截粗制滥造的债务代码。
- 代码审查：代码审查不仅是看代码逻辑是否正确，更是一种让作者理解“代码属于集体”的机制，通过多方把关避免个人不良代码风格导致的技术债蔓延。
- 切斯特顿围栏：面对历史遗留的技术债，在重构或删除原有逻辑前应谨记遵循 chestertons-fence 原则，搞清当初如此设计的上下文，防止盲目重构引入更大的漏洞。