《重构》第三章学习笔记
我们必须培养自己的判断力,来决定在什么时候进行重构。
1.1
DuplicateCode(重复代码)
如果你在一个以上地点看到相同的程序结构,那么将他们合而为一会更好。
1.2
LongMethod(过长函数)
拥有短函数的对象会活得比较好,比较长。
间接层所能带来的全部益处:解释能力(可读性),共享能力(重用性),选择能力(?)。
现在OO
语言基本解决了函数调用所产生的开销。
“
你应该更积极进去的分解函数。我们遵循这样一条原则:每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个函数中,并以其用途(而非实现手法)命名。我们可以对一组甚至短短一行代码(拥有复杂逻辑,难以理解)做这件事。哪怕替换后的函数调用动作比函数自身还长,只要函数名称能够解释其用途,我们也该毫不犹豫的这么做。关键不在于函数的长度,而在于“做什么”和“如何做”之间的语义距离。
”
“如何确定该提炼哪一段代码?一个很好的技巧是:寻找注释。它们通常是指出“代码用途和实现手法间的语义距离”的信号。如果代码需要用注释来说明其用途,那么就要考虑把这段代码提炼成独立的函数,并且用注释来为此函数命名。”
复杂条件式和循环液常常是提炼的信号。
1.3
LargeClass(过大类)
如果想利用单一的class
做太多的事情,其内往往会出现太多的
instance
变量。
如果class
中拥有太多的代码,也是“代码重复、混乱、死亡”的绝佳滋生点。
1.4
LongParameterList(过长的参数列表)
过长的产生导致程序难以理解。
1.5
DivergentChange(发散式变化)
“
一个class
受多个外界变化的影响
”,则把这多个变化封装成一个新的类。即“
将总是一起变化的东西放在一起
”
针对外界某一变化所有相应的修改,都应该只发生在单一的class
中,而这个
class
的所有内容都应该反映该外界变化。总的思想就是,封装变化。这个地方和设计模式的想法是一致的。
1.6
ShotgunSurgery(散弹式修改)
和发散式变化不同,每次遇到变化,都要在多个class
中进行小的修改以响应之。他们分散在多处,很容易出错。
这里的主要思想是集中变化。
散弹式修改指的是,“
一种变化引发多个class
的修改
”,发散式变化指的是“
一个class
受多个外界变化的影响
”。
这两种情况下,通过重构,
使“外界变化”和“待修改类”呈一对一关系
的理想境地。
1.7
FeatureEnvy(依恋情节)
某个函数对其他类的数据的兴趣,高过对hostclass
的兴趣。即对其他的类的数据的依赖十分大。
1.8
DataClumps(数据泥团)
数据泥团指的是总是绑定在一起出现的数据。
一个好的评断方法:删除众多数据中的一项数据,其他数据是否是因而失去了意义?如果他们不再有意义:你应该为他们产生一个新的对象。
形成新的对象后,可以根据FeatureEnvy
将一些操作移至此对象中。
1.9
PrimitiveObsession(基本型别偏执)
建立多个很小,但是很灵活的对象。
1.10
SwitchStatements(
switch
惊悚现身)
使用面向对象编程,要少用switch
和
case
语句。而是用多态来替换它。
1.11
ParallelInheritanceHierarchies(平行继承体系)
每当你为一个class
增加一个
subclass
的时候,必须为另一个
class
增加一个
subclass
。一般这两个
class
的前缀相同。
1.12
LazyClass(冗赘类)
类显得多余,没有价值。
1.13
SpeculativeGenerality(夸夸其谈未来性)
这个往往是过度设计的结果:对某种变化的应对,而这种变化没有发生。
1.14
TemporaryField(令人迷惑的暂时值域)
变量只在特定的情形下有效,而并不是所有的情况下有效。很多情况下,这些值域应该不属于此class
,而应该单独的提取成新的类。
1.15
MessageChains(过度耦合的消息链)
用户向一个对象索取另一个对象,然后在向后者索求另一个对象,然后在索求另一个对象——客户与查找过程的航行结构紧密耦合。
1.16
MiddleMan(中间转手人)
对象的基本特征之一就是封装——对外部世界隐藏实现细节——封装往往伴随委托。委托的过度运行,就导致了MiddleMan
。
1.17
InappropriateIntimacy(亲密关系)
两个class
之间的关系过于亲密。比如,花大量的时间探究彼此的
private
成分。
1.18
AlternativeClasseswithDifferentInterface(异曲同工的类)
类名不同,但是功能相似。
1.19
IncompleteLibraryClass(不完美的程序类库)
基础类库无法满足实际的需求。
1.20
DataClass(纯稚的数据类)
它们拥有一些值域,以及用于访问(读写)这些值域的函数,除此之外一无长物。
1.21
RefusedBequest(被拒绝的遗赠)
子类不像继承父类的函数和数据,这往往是继承体系的错误。
如果子类复用父类的行为,但又不愿支持父类的接口,这种情况下RefusedBequest
的坏味道会很强烈。
1.22
Comments(过多的注释)
注释其实是一种香味,更多的情况下它被用作除臭剂:即代码中出现坏味道(设计糟糕的代码),然后用注释“除臭”。这个时候我们应该对这些坏味道的代码进行重构,然后,你会发现注释变成了多余的。
当你感觉需要注释,请先尝试重构,试着让所有的注释都变得多余——代码本身就是自注释的。
注释可以用来记述“为什么做某事”、“打算做某事”、“无十足把握的区域”,而不必记录“怎么做”。
2
构筑测试体系
如果你想进行重构,首要前提就是要拥有一个可靠的测试环境。
“编写优良的测试程序,可以极大的提高我的编程速度,即使不进行重构也是如此。”
2.1
自我测试代码(Self-testingCode
)的价值
“Class
应该包含他们自己的测试代码。”
“每个Class
都有一个测试函数,并用它测试自己这个
Class
。”
确保所有的测试都完全自动化,让它们检查自己的测试结果。
只要写好一点功能,就立即添加测试。
一整组(asuiteof
)测试就是一个强大的“臭虫”侦测器,能够大大缩减查找“臭虫”所需要的时间。
“实际上,编写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候,先写相应的测试代码。听起来离经叛道,其实不然。填写测试代码其实就是问自己:添加这个功能需要做什么。编写测试代码还能使你把注意力集中于接口而非实现上头(永远是件好事)。预先写好的测试代码也为你的工作按上一个明确的结束标志:一旦测试代码运行正常,工作就可以结束了。”
分享到:
相关推荐
详细描述了在设计和编码中的21中代码坏味道,让我们知道什么样的代码方式是容易给后续维护带来极大影响的问题。
NULL 博文链接:https://takemind.iteye.com/blog/2312244
代码坏味道与启发--《代码整洁之道》总结.pdf
附件是在读完《重构 改善既有代码的设计》之后,为代码的坏味道所撰写的总结文档。
该文档是以前整理的笔记本,主要是针对代码坏问道的一些描述和一些解决办法。东西都是摘录的,虽然距离现在差多十几年,但是感觉还是可用的,所以分享一下。
最近一段时间,我参与了几次代码审查,发现了5种出现次数较多的代码坏味道,总结如下
代码的坏味道 重构方式对应表 DOC 可打印.
java代码的TOP10的坏味道,我们TOP10的坏味道主要如下: TOP 1 —— 返回值处理 A: 被调函数执行结果对业务流程有影响时,调用者却没有处理其返回值。 包括:可能导致空指针访问、缺少回退处理(资源泄漏等)。
重构-改善既有代码的设计之代码的坏味道举例说明.md
代码坏味道 什么是好代码? 什么代码复杂度? 怎么解决代码复杂性? 重要设计模式
25种代码坏味道总结+优化示例 聊聊日常开发中,如何减少bug呢? 工作四年,分享50个让你代码更好的小建议 写代码有这16个好习惯,可以减少80%非业务的bug Java日常开发的21个坑,你踩过几个? CAS乐观锁解决并发问题...
NULL 博文链接:https://aqxiebin.iteye.com/blog/1579688
重构原则 代码的坏味道 简化函数调用 重构,复用与现实 重构工具
运行效果:您的项目概览,并且可以对代码打分(百分制)根据各自的坏味道数量建立文件索引(对不同文件按照改动频率、复杂度、重复度和坏味道4个维度进行综合评定代码质量等级)坏味道检测索引可以查看具体的类文件中...
任何一个傻瓜都能写出计算机可以理解的程序,只有写出人类容易理解的程序才是优秀的程序员
用于代码异味重构的 Android Studio 插件。 它能够修复特定于 Android 的代码异味和/或建议适当的重构来解决它们。 该插件支持以下代码异味: 自动重构: 初始化 OnDraw (IOD) 重启动服务 (HSS) 刚性警报管理器 (RAM...
重构-改善既有代码的设计+中文版代码重构 代码的新思维 何为优秀代码 代码的坏味道 如何重构 设计重构 设计的基本原理 重构到模式 架构重构
刘伟老师关于重构技巧的讲解,通过识别代码中的坏味道,并通过相关的技巧去重构代码以提高代码的可复用性。
第3章 代码的坏味道 75 第4章 构筑测试体系 89 第5章 重构列表 103 第6章 重新组织函数 109 第7章 在对象之间搬移特性 141 第8章 重新组织数据 169 第9章 简化条件表达式 237 第10章 简化函数调用 ...
于是萌生想做一本重构工具书的想法,本来打算自己重新将重构书的内容再整理归类一下,后来发现原书的目录编排就很适合做工具书,包括坏味道分类,重构手法归类等,都有了一个比较系统的整理。因此,我利用空余时间...