重构 9.0分
读书笔记 第三章 代码的坏味道
tokyo

没有任何度量比得上见识广博者的直觉。 在我看来,一篇好文章应该是简单、形象、易懂的。 再次意识到,设计模式使用方面的确是很多的! 阅读介绍经验的书籍时,你如果有足够的经验,那么会引起共鸣,也会有更好的理解。 利用“臭味”条款来选择对应的方法。观察重要的特征。 # 重复的代码。尽可能减少。 类中的重复方法合并; 子类互相重复的方法提炼为父类的方法(我认为还得看方法的重要程度,要是一千个子类中两个子类重复了,那么不应该提炼到父类中); 类似的方法提炼出相同部分的子过程; 不同的算法做同样的事情,利用简单的、清晰的替换掉另外一个。 两个无关类有相同过程,则应该看情况决定是否应该提炼出第三个类。 # 过长函数。拥有短函数的对象会活的比较长。 程序愈长愈难理解。 当我们感觉应该给一个函数加注释的时候,我们就应该把这部分提炼成独立函数,并以用途命名,(简单易懂,我喜欢),哪怕替换后的函数调用比函数体还长,只要能够说清楚干了什么,也值得这样做。 如果参数太多,那么应该利用查询代替参数,亦或是直接重写函数。 注释、条件、循环都是提炼的信号。 # 过大的类。 变量过多。。方法过多。。 提炼方法,消除过多代码。 # 过长参数列。 用方法替换参数,请求数据。 # 发散式变化。一个类对应多种变化,则应该分裂类。 针对某一外界变化的相应修改,都应该只发生在一个类中!??? # 霰弹式修改。一个变化对应多个类,则应该合并。 把所有需要修改的代码移动到同一个类中。 # 依恋情节。 函数应该放在它依赖最多数据的那个对象。 # 数据泥团 用新类代替重复出现的数据? # # 面向对象,少用switch。因为switch重复,多态可以带来更好的解决…… # 平行继承体系。消除这种依赖,利用引用? #…… 消除冗余的类;删掉不用的功能;不用为将来打算太多? 把临时变量提炼到method object中;过度耦合;利用继承消除过多的中间代理;消除过度亲密的类,用代理代替继承;合并异曲同工的类?;弥补不完美的类库;封装数据类。 # 如果要注释代码,那么提炼方法;如果要注释方法,那么重新命名方法;如果需要注释说明规格,那么用断言。 想写注释时,先重构。 当不知道做什么的时候,才是注释的良机,你可以记录下你的想法,你将来想干什么?

0
《重构》的全部笔记 66篇
豆瓣
免费下载 iOS / Android 版客户端