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