重构，你太美丽了

今天又开始把很久之前半途而废的重构拾了起来，之前看重构时还是大二，大三的时候，不太了解里面很多编写的理念，以至于不懂为什么这样写，当时好像看了几片就跟这本书拜拜了，想想也是，当时代码基础也不牢固，硬着头皮看完也是没有用，索性将时间抛给了我钟爱的游戏。现在说说咱的重构这本书吧。

第一章介绍的代码是很好的，可以从代码中学到很多重构的概念，至少会将面向对象从代码的角度认识的比较清楚，我觉得这本书里看的到最好的东西不仅仅是介绍How to Refactor，而是清楚的让读者知道Why have to Refactor。

基于这种书的好处，觉得这本书应该是需要了解的，至少要通读一遍，了解自己的代码需要如何进行修改，不仅仅是程序员的工作，觉得从管理方面来说，也会让同事们的代码更加规范，授人以鱼不如授人以渔，那就把这本书介绍给他们看吧，包子哥正好有纸质版，明天接过来看的会更加方便。

一直想弄个小组图书角，将一些经典的书都放在一起，空闲时能借来稍微看下，丰富自己，如果能有个技术交流会就更好了，时间不必太长，6人小组每月两次，下班后一人45分钟讲解，30分钟相互讨论，另一人15分钟介绍下次的内容，一个人三个月讲一次，不费什么时间，这也算丰富他人，说的有点偏，想法跳跃了。

接着说重构的事，概念这个还是说下，摘自第二章，书中对重构有两重含义，一个名词一个动词，我想说的并不是那两个看起来很别扭的解释，我觉得这个解释比较合理，重构是整理代码使之更容易被理解和修改。目的同样也是这个，我觉得书里面的一句话挺好的，而且工作中也一直秉着这个原则，重构本来不是一件“特别拨出时间做”的事情，重构应该随时随地进行，不应该为重构而重构。

重构总是将开发进度与质量性能辩论开来，在什么时候重构，开发进度上会带来多大的风险，如果已经实现的功能，重构后的性能是否会有变化等等一系列问题。开发进度上的问题，我觉得重构不一定会拖累进度，相反可能会加快进度，如果代码随写随着重构，在后期相似功能以及测试点的插入都会很方便，而且在BUG查找时也会因为重构的代码简洁清晰所以BUG发现起来异常轻松，再加上需求的变更，如果代码构建的扩展性较高，变更的需求很轻松就能实现，所以这个进度上的问题我觉得在于重构上一个“度”的把握，是靠经验来积累出来的；再来说说质量性能，书中提到了一个观点：要做良好的分解程序。就是说开发时暂时不管性能问题，而是将功能实现，在整体功能实现完成后，再通过测试找出影响性能质量的瓶颈，再针对这样的一个过程进行优化，这样的好处在于前期开发不需要进行很多臆想性的优化，在真正软件使用过程中根本不涉及，或者涉及的情况极少，还有就是在后期性能优化时也是特别方便，因为功能已经都开发OK，从整体测试方向查询每个热点位置，针对热点来进行优化，注意力也都集中在这里，工作起来也很方便。这些我感觉对于一个重构的过程来说都是相当重要的。

总的先看了前两章，这几天书都是并行发展的，也许过过又看其他书了，不过我敢肯定的是，这本书六月中旬一定会看完这本书。