文章说明：
1.重构：改善既有代码的设计第4篇
当我讨论重构时，常常有人问我应该怎样安排重构时间表。是不是应该没两个月就安排两周时间来重构？
大多数时候，我反对专门留出时间来重构。在我看来，重构不应该是专门抽出时间去做，而应该是随时随地的进行。你不应该为重构而重构，是因为你想做其它事，而重构可以帮你把那些事做的更好。
事不过三，过必重构
Don Roberts给我一条准则：第一次做某事就尽管去做，第二次做相似的事你会略微皱眉，但无论如何你还是做了，第三次再做相似的事，那么就重构吧。
添加功能时重构
最常见的重构时机就是当你需要添加新功能的时候。此时重构的第一个原因往往是因为重构可以帮助你更好的理解你需要修改的代码。这些代码可能是其它人写的，也可能是以前你自己写的。无论何时，只要我想理解代码的功能，我都问自己：是否可以重构这些代码让我更快的理解它们。重构必然让我在下次看见这些代码时能够更容易的理解，更重要的是在前进中把代码的结构理清，我可以从中理解更多的东西。
另外一个驱使我重构的原因是这里的设计不能让我很容易的添加新功能。我审视代码的设计然后对自己说“如果我这样设计，添加新功能会容易很多”。这时，我不会懊恼，我通过重构来改正错误的设计，这样我可以更容易的添加新功能，这也是最为便捷的方法。重构是一个快速流畅的过程，一旦重构完成，新功能的添加就会更为的便捷容易。
修正bug时重构
修正bug的过程中使用重构往往是因为它可以让代码更具可读性。当我试着理解代码时，重构可以帮助我加深理解。我发现以这种方式来处理代码，常常能够帮助我找到bug。你可以这么想：如果你收到一份错误报告，这就是需要重构的信号，因为你的代码还不够清晰，不能让你一眼就看出bug。
评审代码时重构
很多公司都有常规性的代码评审，因为它可以改善开发状况。代码评审有助于有经验的开发者把经验和知识传授给缺乏经验的开发者；也有助于开发者从各个方面理解大型的软件系统；同样有助于写出清晰的代码。我的代码对于我来说是清晰的，但是对于团队的其他成员却未必。这是无法避免的，因为让开发者设身处地为那些不熟悉自己所做所为的人设想，实在是太困难了。代码评审让更多的人有机会说出有用的点子，毕竟我在一周之内想出的好点子有限，其他人的贡献让我的生活更舒服，所以我总是期待更多的代码评审。
我发现重构可以帮助我评审他人的代码。在我使用重构以前，我可以先阅读代码，得到一定程度的理解，然后给出一些建议。但我想到一个新点子，就会考虑是否可以通过重构很容易的实现它。如果可以，我就重构。这样做过几次后，我可以把代码理解得更透彻，提出更多恰当的建议。于是，我得到了更高层次的认知，但是不使用重构，我是无法得到这样的认识的。
重构还可以帮助代码评审得到很多具体的成果。它收获的不仅仅是这些点子，更重要的是实现这些点子将让你从实践中得到更多成就感。
为了让过程正常运转，你的评审团队必须精炼，就我的经验：一个评审者搭配一个原作者，共同处理这些代码，评审者提出建议，然后他们共同决定这些修改是否能够通过重构轻松实现。果真能够如此，就一起着手修改。
如果是比较大的评审工作，那么，在一个大团队内保留多种观点通常会更好一些，此时，如果直接展示代码往往不是最佳方法。我比较喜欢运用UML图展现设计，并以CRC卡展示软件情节。换句话说，我会和某个团队进行设计评审，而和单一评审者进行代码评审。
