一些技术债是显而易见的。
数据结构不合理可能会导致代码错综复杂。当需求不断变化时，代码可能包含以前方法的痕迹。有时代码写得很匆忙或者就是草率。
这种技术债很容易去讨论，因为它非常明显。它变现成 bugs、性能问题和添加功能的困难。
还有另一种更隐密的技术债。
可能测试时有点慢，没慢到和爬一样 —— 但刚好让你不打算去查看 bug 并把它添加到积压工具中。也许你不相信部署脚本，因此你跳过了这个额外版本；也许抽象层使得定位性能回归变得太难，所以你在代码中留下了 TODO；有时单元测试太严格，所以推迟尝试一个有趣的新想法，直到你发布了计划的功能。
这些东西都不是破坏者。如果有的话，它们可能看起来像是不专注，抱怨它们是徒劳的。毕竟，如果它们真的很重要，尽管冲突你也会做这些，不是吗？
所以这些事情永远不会完成。它们本身似乎不够重要，冲突杀死了它们。其中一些探索可能无关紧要，其中一些可以重新定义你的项目。
你永远都不会知道。这就是为什么你必须积极的减少冲突，就像你项目的命运离不开它，因为它确实存在。
像没人看的那样修复。
翻译原文Fix Like No One’s Watching(2019-02-15)
