像没人看的那样修复

一些技术债是显而易见的。

数据结构不合理可能会致使代码错综复杂。当需求不断变化时，代码可能包含之前方法的痕迹。有时代码写得很匆忙或者就是草率。

这种技术债很容易去讨论，由于它很是明显。它变现成 bugs、性能问题和添加功能的困难。

还有另外一种更隐密的技术债。

可能测试时有点慢，没慢到和爬同样 —— 但恰好让你不打算去查看 bug 并把它添加到积压工具中。也许你不相信部署脚本，所以你跳过了这个额外版本；也许抽象层使得定位性能回归变得太难，因此你在代码中留下了 TODO；有时单元测试太严格，因此推迟尝试一个有趣的新想法，直到你发布了计划的功能。

这些东西都不是破坏者。若是有的话，它们可能看起来像是不专一，抱怨它们是徒劳的。毕竟，若是它们真的很重要，尽管冲突你也会作这些，不是吗？

因此这些事情永远不会完成。它们自己彷佛不够重要，冲突杀死了它们。其中一些探索可能可有可无，其中一些能够从新定义你的项目。

你永远都不会知道。这就是为何你必须积极的减小冲突，就像你项目的命运离不开它，由于它确实存在。

像没人看的那样修复。

翻译原文Fix Like No One’s Watching(2019-02-15)