像没人看见一样修复
February 15, 2019
有些技术债务是显而易见的。
比如，不合适的数据结构可能导致代码变得复杂难懂。当需求不断变化时，代码里可能还残留着之前方案的痕迹。有时候，代码是匆忙写出来的，或者本身就比较粗糙。
这种技术债务很容易讨论，因为它非常直观。它会表现为 bug、性能问题，以及新增功能时的各种困难。
但还有另一种更隐蔽的技术债务。
也许测试套件有点慢。不是慢到无法忍受——只是慢到让你懒得去查一个 bug，转而把它加入待办列表。也许你对部署脚本不太信任，于是就跳过了那次额外的发布。也许抽象层太多，定位性能回退变得太麻烦，于是你在代码里留了个 TODO。还有时候，单元测试太死板，让你把尝试一个有趣新想法的计划推迟到所有既定功能上线之后。
这些问题都不是致命的。如果说有什么影响，可能只是让人分心。抱怨它们似乎有点矫情。毕竟，如果它们真的那么重要，你肯定会克服阻力去做，不是吗？
于是，这些事就一直被搁置。它们本身看起来都不够重要。**阻力让它们夭折了。**有些探索可能无关紧要，但有些却可能彻底改变你的项目。
你永远无法预知。这就是为什么你必须主动减少阻力。要像项目的命运系于此一样去做。因为事实确实如此。
像没人看见一样修复。
Pay what you like