何时不重构：
不需要修改的代码：如果某段代码运行稳定，没有bug，并且满足当前的需求，同时也不计划在未来对其进行扩展或修改，那么就没有必要去重构它。这样的代码可以被视为一个“黑盒”，只要其输入和输出行为保持不变，内部实现就不需要过多关注。
重构的风险如何解决：
良好的自测：在重构之前和之后，都需要进行充分的测试以确保代码的功能没有因为重构而受损。这包括单元测试、集成测试和系统测试等。良好的自测可以大大降低重构的风险。
测试驱动开发（TDD）：测试驱动开发是一种先写测试代码再写实现代码的开发方法。在重构过程中，使用TDD可以确保重构后的代码仍然满足原有的功能需求。通过先编写测试用例，然后再编写满足这些测试用例的代码，可以确保重构的每一步都是安全的。
代码审查：在重构完成后，进行代码审查也是一个重要的环节。通过同事之间的代码审查，可以发现可能存在的问题和遗漏的测试用例，从而进一步提高代码的质量。
备份原始代码：在进行重构之前，最好先备份原始的代码。这样，如果在重构过程中出现了不可预期的问题，可以迅速回滚到原始的状态，避免造成更大的损失。
重构是一个需要谨慎进行的过程。在决定是否进行重构以及如何进行重构时，需要综合考虑多种因素，包括代码的现状、未来的需求、团队的实力和资源等。同时，也需要采取一系列的措施来降低重构的风险，确保重构的成功。