不要重构代码

这是很久以前有人给我的建议。可惜我记不清是谁给的，所以无法准确指出（虽然他们可能也在别的地方听过）。但我还是决定分享一下。

什么是重构？我相信我们可以找到很多定义。但在现代软件开发过程中，它常常被理解为任何不添加、修改或删除功能的代码变更。换句话说，它是一种非产品工作。实际上，它常常成为一个模糊的术语，并导致产品利益相关者和开发团队之间的紧张关系。

我们谁没在状态会议上听过这样的话：“昨天我花了大部分时间重构了围绕 X 的代码”？我知道我听过。而且，我可能不止一次说过这样的话。这是什么意思？你到底做了什么？这隐藏在“我重构了”这句话的背后。“我做了一项你不会理解的重要技术工作”是另一种表述方式。

这正是“重构代码”的问题所在。很多时候，它意味着在做一件非常重要的工作，但却与偷懒没什么区别，比如无缘无故地重命名变量。

这就是我所说的“不要重构代码”：在谈论你做过、正在做或计划做的事情时，用不同的词语。不要“重构”。试试这些：

• 我提高了代码的性能（确定了 N+1，发现处理大量数据效率低下）

• 我让代码更容易被修改（主要是因为我们预测现在我们会更频繁地修改这个区域）

• 我使代码更具防御性（如果使用不正确的参数运行，则会尽早失败并显示明确的消息 - 因为其他团队错误地使用它并导致细微的错误）

• 我为未经测试的区域添加了测试（好的理由：因为它最近失败了几次；坏的理由：为了增加我们的任意代码覆盖率指标）

• 我添加了更多日志/仪器（以便我们更好地了解发生了什么）

• 我修改了代码以符合我们的新样式指南（因为我们会经常修改它）

这样的沟通不仅能让其他人更容易理解修改的内容，还能帮助你判断计划进行的更改是否真的有效。不用再躲在“重构”这个笼统的术语后面，也能让你的同事更专注于修改，更容易审核。