再谈对“重构”的学习

        数月前，我曾经写过一篇博文《在代码重构中蜕变》，文中提到了我对重构的一些认识，今天再谈重构，缘起于近期针对重构进行了6次技术分享，每次对应《重构——改善既有代码的设计》一书中的一章内容，在此过程中与团队一起再学习了一次重构，因此，这次再谈重构，就从学习的角度说起。

        当再次拿起这本书时，想到的就是第一次阅读时的体会。几年前，第一次打开书，读完了第六章——重新组织你的函数，知道了大体上重构是怎么回事，如何完成，然后就再也读不下去了。当时心里想，虽然书里列出了若干条重构手法，但看上去好像千篇一律了，像提炼函数、将函数内联、将临时变量内联……实在是太简单了，只要我想改，随手就把代码改了，还要这些手法干嘛呢？这就是我当时的实际想法，由此，我就学完了重构，书也束之高阁了。

        再学重构时，我认识到了很多当时的局限。

        首先，重构手法只是便于表达和记录，不是要死记硬背的东西，更不是放之四海而皆准的数理化公式定理。我们要学的不是每一条手法的名称、动机、作法，而是要深刻领会每一条手法背后所适用的场合。我们可以一个名称都记不住，但我们要形成用这种思路提升代码可读性的认识。

        其次，重构本身是一种理念。学习重构，就是要学习从能识别出代码中的坏味道，到能消除代码中的坏味道的思维过程，就是要形成这样的意识，并且能在实际工作当中加以实践运用，就是要想方设法的让代码清爽。一些必要的手法可以开拓我们改进代码的思路，但并不是只有这种方法才行。

        再次，重构还是一种决策过程。程序是平衡的，不仅架构师在面对各种决策，所有工程师其实都要面对，要在各种约束中做出选择。重构也是如此，我们看到很多的重构手法是互相矛盾的，比如‘将单向关联改为双向’对应的就是‘将双向关联改为单向’，比如‘提炼子类’与‘提炼超类’等等，具体用哪种更合适，那是需要我们在实际情况中去决策的。

        最后，重构从更广泛的意义上来讲，里面除了有修改代码的方法以外，更包含了编程标准或规范，以及程序设计思维。里面的很多手法就是设计模式，所以学习重构，就不能只把它当成一个修改代码的手段来学了。

        很显然，重构对于提高代码质量，提高编码能力是非常重要的，那么怎样才能快速的掌握这一工程师必备技能呢？一句话，在明白重构本质的前提下去实践。

        看书无疑还是枯燥的，只有把它转化成实际应用，才能加深认识。如果手中有实际的代码，不妨从自己能把握的小范围开始，重命名、提炼、内联、搬移……看看改完了是否让别人能更容易理解。如果手中没有实际代码，可喜的是书中的范例很不错，要在IDE中尝试着来做一下。但要注意三点：一是要频繁测试，尤其是产品代码，一定不能改变现有的功能，不能引入新的bug；二是只在自己能控制的范围内修改，不要修改其他人的代码甚至整体结构，慎重；三是书中的代码是示意性的，很多是编译通不过的，要自己亲自动手才能领会其中的细节。

        我想，对重构有了正确的认识，再加上勤于实践，把思路着重于重构手法的应用场景而不是作法细节甚至对手法名称的背诵，就一定能够用最短的时间掌握这种技能了。

——欢迎转载，请注明出处 http://blog.csdn.net/caowenbin ——