重构--改善既有代码的设计(Refactoring Imporving the Design of Existing Code) 笔记(思路整理)
一本非常经典的书籍,Martin Fowler的杰作。最近几个月工作上接手一些别人的代码,去维护修改,刚好能用得着,并且有很多牛人都推荐这本书,我手上这本是从阅览室借的,两个月了,刚开始是挑着读书的,最近催着还书,于是最后4天里花了不少时间看了个大概。
什么是重构?在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。
第一章以一个经典的案例开始让读者对重构有一个大概的认识,如何一步一步改进代码质量。(以一个实际案例开始,不错!)
重构目的:1,改进软件设计;2,使软件容易被理解;3,助你找到bug;4,助你提高编程速度
重构时机:1,添加功能时;2,修补错误时一并重构;3,复审代码(code reviews)时一并重构
重构难题:1,数据库;2,修改接口;3,难以通过重构手法完成的设计改动
何时不该重构:重构还不如重写来得快的时候,即可放弃重构。
重构与设计:彼此互补。
重构与性能(performance):作者观点:
除了对性能有严格要求的实时(real time)系统,其他任何情况下[编写快速软件]的秘密就是首先写出可调(tunable)软件,然后再调整它以求获得足够速度。良好的代码结构,更能发现性能瓶颈及更易进行有针对性的优化。
一,代码的坏味道(Bad smells in Code)
1,duplicated code(重复的代码)
2,long method(过长的函数)
3,large class(过大类)
4,long parameter list(过长参数列)
5,divergent change(发散式变化)
一个class受多种变化的影响]针对某一外界变化的所有相应修改,都只应该发生在单一class中
6,shotgun surgery(霰弹式修改)
[一种变化引发多个class的修改] 与上一种情况一样,我们都希望外界变化与待改类呈现一对一的理想境界
7,feature envy (依赖情结)
bad smell:函数对某个class的兴趣高过对自己所处之host class的兴趣。有时候,一个函数往往会用上多个class特性,那么它该置在何处呢?作者的观点是:判断哪个class拥有最多的[被此函数使用]的数据,然后把这个函数和那些数据摆在一起。
8,data clumps(数据泥团)
问题绑在一起出现的数据放进自己的对象中,取代以前的值域。使其更具feture envy。
9,primitive obsession (基本型别偏执)
10,switch statements (switch语块声明)
11,parallel inheritance hierarchies(平等继承体系)
bad smell:当你为某个class增加一个subclass,必须也为另一个sclass增加subclass。如果你发现某个继承体系的class名称前缀和另一个继承体系的class名称前缀完全相同,即为bad smell。
12,lazy class (冗赘类)
删掉没用或用处不大的类。
13,speculative generality
bad smell:有些人总想着,"将来我们总有一天需要做这件事的"并因而企图以各式各样的挂勾和特殊情况来处理一些非必要的事情。那么做的结果是往往造成系统更难理解和维护。如果所有装置都会被用到,那就值得;如果用不到,只会挡你的路,refactoring it.
14,temporary field (令人迷惑的暂时值域)
bad smell:对象内,某个instance变量仅为某种特定情势而设。
15,message chains or method chains(过渡耦合的消息链)
办法:hidden delegate,extract method,move method.
16,middle man (中间转手人)
办法:remove middle man,inline method,replace delegation with inheritance.
17,inappropriate intimacy (类之间不适当的亲昵关系)
18,alternative classes with different interfaces
[b]19,imcomplete library class (不完美的程序库)
20,data class (纯稚的数据类)
21,refused bequest (被拒绝的遗赠)
bad smell:继承
22,comments (过多的注释)
最后总结一下:围绕这几个字“易读,易扩展,易维护,高效开发”,应该算是作者的是编程技巧或者经验之谈吧?