《重构-改善既有代码的设计》读书笔记--第一章--1

    工作之余修炼内功，买了本重构好久也没仔细看下，太不应该了，今天开始先做一个简单的表示决心，然后每天读一些，争取学到一些重构的皮毛，给代码一个提升质量的机会。

    其实从序言就能感觉到这是一本好书了，里面提到了重构的定义：在不改变软件可观察行为的前提下改善其内部架构。重构不会更改软件的外部行为，软件该怎么用还怎么用，不会对用户使用产生影响或者产生极小的影响；广义上来说也可以是一个类，重构后的类对外开放的方法还是实现原有的功能，并不会让调用者感到一丝一毫的差别。其次再说是“改善”，改善不是重写，只是对内部进行一点“装修”，让外人看起来内部更加井井有条，而不是打着重构的大旗进行重写。

    第一章

    作者通过一个例子来展示重构的强大魔力，这是一个非常短小精悍的实例，代码不多，思想不少。

    作者拿到这个程序的时候，首先理了一下业务逻辑，因为是小程序，业务逻辑是一目了然的，但是作者的重构方法并不是马上建立在已有的业务逻辑上进行大刀阔斧的修改，而是一点点的行进。下面看看作者是怎么前进的：

    1.首先对最为冗长的函数进行切割，提取了一个很长的Switch..Case语句作为独立函数A并修改了独立函数的变量名等，这让新的函数更具有可读性。这里说明了重构的一个很重要的好处就是可以进行解释！当你觉得代码冗长，不能一眼而明其作用的时候，就可以尝试从其中分离出来函数；抑或是当你觉得某段代码不是很好理解需要一段注释的时候，也试着把他重构成一个新的函数来解释他。

    2.独立出来的Switch..Case语句的函数A如果放在原来函数的并列固然没有错误，但是作者考虑到这个函数的逻辑功能，一个函数的一般放置在他所有使用的数据的类里面，因此作者对这个新函数进行了搬运。做到这里感觉上是理所应当的，这里说到了一个说法：函数放置在他所使用的数据的类里面，这是作者长时间进行代码编写才有的下意识行为吧，反正我没有想到这里。

    3.搬运完成后，作者审查原来的函数，发现了一个没有必要的临时变量，这个临时变量指示的就是刚重构完成的函数A所返回的结果，这个临时变量显然是多余的，在调用临时变量的地方直接替换为A函数调用，这样就去掉了一个临时变量。为啥要去掉临时变量呢，临时变量会让函数可读性不好(找半天才能找到一个临时变量)，上面定义了一个临时变量，后面若干次使用他的时候，你可能就会忘掉这是个什么东西，如果用函数调用呢就没这个后顾之忧。我看到这里的时候是有疑问的，这样难道不会影响性能么？如果这个临时变量指示的是一个从数据库里面查询到的结果，倘若多次调用会不会对性能造成影响呢？这个我是觉得要分情况来进行重构，如果这次重构明显要多读取若干次数据库，造成操作延迟，那不重构也罢；如果仅仅增加了一点时间，比如说多增加一次查询，为了程序的干净我觉得还是值得的。

。。。未完待续