最近阅读
Martin Flower
的《重构》，对自己有许多启发，以前认为一些正确的观点现在看来也不那么正确了；同时发现对重构的理解只有在阅读了书之后更加彻底；在阅读《重构》之后我对其中几点有点感触：
1.
在没有具体阅读《重构》之前，我认为重构就是将代码变的容易理解，容易维护，但在阅读了《重构》之后才发现重构不仅可以利用到重新构造已有的代码，也可以帮助我们在阅读代码的过程中增加我们的对代码理解的速度。其实我想每个学习编写代码的同行都在学习的过程中阅读过别人的代码，然后还有可能将别人的代码拿到计算机上编译运行来查看结果表现。实际上我认为这在某种意义上属于重构，只是重构的粒度有多大，或许你修改别人的代码一部分来查看修改的结果，从而帮助自己掌握软件中的更多特性，或者说让自己修改的代码表现出原来的功能。
Martin Flower
说的就是如此，我们如果没有得到别人完整的文档，那我们怎么样才能理解别人的代码来，好的办法就是我们一边阅读别人的代码，一边部分部分的修改他人的代码，然后测试每次修改的结果与以前的结果是否一样，如果一样，那么你的重构代码是正确，那么你肯定能够理解你自己写的代码吧（自己都不理解自己的代码就不要干了）；别人的代码就这样在我们一部分一部分重构当中被我们理解了。
2.
以前我们写代码的时候喜欢设计，设计的我们认为很详细了，然后开始将所有的功能模块都写完，接着再调试，在调试的过程中我们可能花费比写代码长的多的时间。是的，因为你在运行一个复杂的东西，当然不容易搞定了。
Martin Flower
认为我们调试的时间可以不用那么长，原因是我们不能在写完了一个复杂系统的时候再调试，我们可以先建立一个好的测试用例，在写这个测试用例的过程中我们更能对整个系统了解，也能够帮助我们写代码；然后我们一点点的写，写一部分测试一下，保证每次新写的代码都能正确运行，从而当代码写完了，系统调试也完毕了。这样的情况下可以认为我们没有在调试上花时间，我们把时间花在测试和编写代码上了。
3.
以前认为代码当中注释越多越好。
Martin Flower
又一次给我们教训说，写注释是因为你的代码已经不能告诉代码阅读者他的真实意思了。是的，好的代码可以通过很多方式表达其自身的含义，例如变量的名称，函数的名称等；就如一个比较条件判断来说吧，我们有必要的情况下将这个即使很短的条件抽取一个方法，然后用方法名称来告诉读者判断的真实意义，如果这里直接使用条件判断就要让读者迷惑半天，当然这里的前提是给变量和函数起一个合适的名字，这是考验程序员真功夫的地方了。另外，这里说的不是说写注释不好，如我的目的是如果代码可以描述意义了，注释就不需要写了，这样就让你省了一件事情：保证代码和注释的同步，这不是更好。
4.
在之前我也认为重构会花费很大代码，因为我们要理解代码，重新编写；但为了修改
BUG
，
Martin Flower
告诉我们重构是最快的。也许不相信，我也不相信，但他说的有道理，容易修改的
BUG
，当然早就被修改了，那么剩下的
BUG
就很难找了，主要因为代码中的逻辑不清楚，重构可以改变这种情况，让我们的代码有条有理，那么当然
BUG
就无处藏身了。
5.
勇于接受变化。以前认为用户频繁的变化需求是不可理喻，实际上是我们自己不可理喻，他们花钱当然需要能提供高质量的服务；而
Martin Flower
认为不用怕改变，我们有重构工具，重构可以让我们代码任何时候都是清楚的，容易修改的，那么变化是件快乐的事情不再象以前那样艰难了。
6.
重构与性能不是对立的。重构让代码容易理解，而性能让代码变的难以理解，不过我们在开始的时候应该考虑怎么样让代码容易理解和维护，这样我们可以在后面适当的时候对代码的某部分进行轻松的性能改进工作。本人做性能改进工作有段时间了，想从庞大的杂乱无章的、不熟悉的代码中找出性能的
bottleneck
的确不是一件容易的事情，我需要的是理解代码，理解流程，那么如果一个结构很好的代码对于我来说就好对付多了。因此他们不是对立的，性能以重构为基础的。
其实通过重构，最主要的目的是让我们的代码更清晰，更轻巧，更容易被维护，那么也就是我们有良好的代码，于是我们还惧怕什么，什么都可以轻松搞定。同样《重构》认为代码随时都是清晰的、轻巧的，一般你的代码不再具有以上特点，那么我们就需要使用重构了。
本人说不当之处请大家指教。