有时候程序员需要对现有代码重构。但在此之前你要思考以下几点，这能帮你和他人省去大量处理时间(和痛苦)：
- 重组的最佳方法始于现有代码库的评估及测试。这能够帮你理解当前代码中好和烂的部分，你就能取其精华去其糟粕。我们都认为自己可以做的比现在的系统更好…然后我们交付的东西可能不咋地，甚至更垃圾，因为我们没有从以前系统的缺陷中总结教训。
- 要禁得住推翻重来的诱惑。最大程度地重用现有代码。不论这些代码写得多丑，毕竟它通过了测试和审查等。抛弃旧的代码，尤其是已投入生产使用的，就意味着你正在抛弃历经一个月(或一年)的测试和身经百战的代码，但其中有某些变通和修复bug的方法，只是你不知道而已。如果你不考虑这一点，你写的新代码可能会重现已被旧代码修复过的bug。它们会占用你大量的时间、精力和多年的知识积累。
- 大量的小改(增量修改)要比一次性大改好太多了。增量修改允许你通过反馈轻松地衡量对系统的影响，例如单元测试。谁也不想一次看到几百个测试失败的情况吧。那会因为压力和挫败感进一步导致错误的决策。一两个测试失败却很好处理，而且会有更多选择方案。
- 每次迭代后，已通过的现有测试将成为重要的保障。当现有测试不能完全覆盖代码变更时就添加新测试。千万不要不经大脑直接从旧代码中移除测试。表面上看这些就测试已无法适应你的新设计，但为什么要加入此测试的原因是非常值得深入研究的。
- 个人偏好和自我不应该在重构的时候出现。如果一些地方没出问题，你干嘛要修复它呢？代码的风格和架构都不应该有你的个人偏好，更不该是重构的理由。自以为你可以做得比之前的程序更好，也不该是重构的理由。
- 新技术也不足以成为重构的理由。现有代码所使用的技术已经落后于当今是最糟糕的重构理由之一，之二便是我们认为新语言和框架可以更优雅地解决这些事。除非成本收益分析显示新的语言或框架可以让功能性、可维护性以及生产力得到显著改善，否则最好保持原样。
- 永远记住人是会犯错的。重构不可能保证每次都更比以前的代码好甚至完美。我也曾看到并参与几次重构失败的情况。它不完美，因为这是人类的功劳。
