『重构--改善既有代码的设计』读书笔记----序

    作为C++的程序员，我从大学就开始不间断的看书，看到如今上班，也始终坚持每天多多少少阅读技术文章，书看的很多，但很难有一本书，能让我去反复的翻阅。但唯独『重构--改善既有代码的设计』这本书让我重复看了不下3遍，今天我重新拿起这本书开始了第四遍的阅读。

    我后来仔细想了想为什么我会对这个书如此“迷恋”？忽然之间，我意识到这本书真正意义上给我带来了工作的改变。不像别的技术书籍，可能你看过之后，你脑子里有个印象，但对于实践这块不能立马就做，所以往往印象不深。而这本重构，在你看完之后，你可以立马开刀阔斧去进行真正意义上的实践，而且收获颇多，乐此不疲。

    接下来的日子，我将进行第四次『重构--改善既有代码的设计』的阅读，对于这本书，我也有了不一样的感情在里面。以前对于看书，没有写读书笔记的习惯，希望在这本书给我带来各种便利的同时，我也能够为它“做点什么”。呵呵，其实也是给自己加深印象的一种途径。因为“重构”我感觉目前国内开发者还不是特别熟悉，甚至有些程序员写了几年代码之后都不知道设计模式是什么东西。遇到项目，遇到代码，往往是想到什么就写什么。当遇到代码修改或者增加功能的时候，不会去看扩展性或者兼容性，直接语句一贴就完事。对于这种程序员，我真的希望你可以好好的静下心来想想，这些年来你代码能力有没有实质上的长进。

    拥有“代码洁癖”其实是一种很难能可贵的事情，有时候看到一团糟糕代码，心里会去想对他进行重构。不要怀疑这样会不会耽误自己的效率，重构之后添加功能往往能够更加如鱼得水。

    今天写的是序，为了便于有文有料，还是总结几个可以直接上手的要点给大家，之后我的出法应该就是针对重构列表中的每一条，都出一篇对应的文章。只有这样，我才能真正意义上的去重视那些简单的，和坦然接受那些复杂的重构手法。下面先列举几个比较有效的重构原则。作为序篇的总结。

    1. 有时候遇到大长段函数，需要进行Extract Method的时候，往往找不到一个比较好的切入点。其实这里有一个小窍门，就是寻找逻辑泥团，那么什么是逻辑泥团？其实很简单，就是那种有switch,if...else,for,while等循环判断的逻辑结构。往往提炼这种到单独的函数可以更加有效。

    2. 对于函数自身来说，函数内部的参数命名其实也很重要。有些同学可能会觉得接口的命名似乎比内部实现的参数命名更加重要，但你要知道，这个函数很可能之后还是由你去修改去增加功能。如果没有一个好的参数命名习惯，你又要重新开始去思考，这个变量是用来干什么的，这个时间就浪费掉了。

    3.  如果函数中使用的参数都不是该类所持有，应该考虑是否要Move Method到别的类去。对于类中函数，如果有函数内部使用的变量跟本类没有任何关系，那么说白了，这个函数不属于这个类。那么就将这个函数移到他需要的参数所在的类中去。别以为这个小动作没什么改变，这其实已经改变了类与类之间的耦合关系。从之前的实现耦合到现在的接口耦合，耦合度直接下降了一个级别，这是有目共睹的。

    4. 对于一些临时变量，如果可以通过函数获得，那么你就Replace Temp with Query，用函数将他替换，不要担心性能效率问题，记住28原则，80%的效率问题仅仅掌握在20%的代码身上。

    5. 针对变化，转移函数。如果一个函数中需要同时用到两个类以上的变量，那么你需要去观察，这个函数中这些类中变量，在将来比较容易变化的是哪些。优先将这个函数放到变化类中去。这样对于类型码这种，你当然可以利用面向对象的法宝--多态来取代switch语句了。这里还有个小技巧，如果你觉得如果在类的生命周期中可能会改变类型，那你就别对这个类做继承，你所要做的就是加个间接层，State/Strategy模式。通过委托来进行生命期的行为改变，还记得David Wheeler的名言吗？----计算机科学中的大多数问题都可以通过增加一层间接性来解决。

    结语: 其实个人很喜欢测评界的ZEALER，因为他们的精神就是想到什么就去做，与其思来想去要不要真正来篇读书笔记，不如狠下心来直接来一篇 『重构--改善既有代码的设计』读书笔记----序 ： ）