18、代码重构与安全保障：开发者的必备指南

代码重构与安全保障：开发者的必备指南

一、何时不应进行代码重构

代码重构有其积极的一面，它能促使开发者思考改进代码的方法。然而，重构也可能走向极端，成为目的而非手段。当开发者对每一段代码都试图进行改进，甚至为了改变而改变，却不考虑其实际益处时，这不仅会浪费自己的时间，也会让团队成员因不断适应变化而浪费精力。

足够好代码的评判标准

在判断是否进行重构时，可参考以下标准：
1. 重构理由是否仅为“更优雅” ：如果只是因为觉得代码更优雅而重构，这是一个危险信号。优雅是主观且模糊的概念，缺乏实际意义。应提出具体且有价值的理由，如“通过减少每次使用组件时的样板代码，使组件更易用”“为迁移到新库做准备”“消除对组件 X 的依赖”等。
2. 目标组件的依赖情况 ：若目标组件依赖的其他组件较少，说明它在未来更易于移动或重构。若重构无法帮助识别代码中的刚性部分，可先推迟，待有更完善的改进计划时再进行。
3. 测试覆盖情况 ：若组件缺乏测试覆盖，尤其是依赖众多时，应避免重构。因为缺乏测试意味着开发者不清楚自己的操作会带来什么后果。
4. 是否为公共依赖 ：即使有充足的测试覆盖和合理的理由，对公共依赖进行重构也可能影响团队的工作流程。若重构的收益不足以弥补成本，应考虑推迟。

重构总结

• 接受重构，因为它带来的好处远超表面。
• 可逐步进行大型架构更改。
• 利用测试减少大型重构工作中的潜在问题。