重构——改善既有代码的设计 读书笔记

本文详细介绍了重构的概念、原则,列举了代码中的不良味道,如神秘命名、重复代码等,并强调了构筑测试体系的重要性。章节内容涵盖了封装、搬移特性、数据组织、条件逻辑简化、API重构以及处理继承关系的重构技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

第一章:重构,第一个实例

第二章:重构的原则

第三章:代码坏味道

第四章:构筑测试体系

第五章:介绍重构名录

第六章:第一组重构

第七章:封装

第八章:搬移特性

第九章:重新组织数据

第十章:简化条件逻辑

第十一章:重构API

第十二章:处理继承关系


第一章:重构,第一个实例

  • 总结:通过一个简单的示例来理解重构的基本过程和效果

第二章:重构的原则

  • 总结:重构的定义、原则、以及重构与性能的关系
    • 何谓重构
      • 重构(名词):对软件内部结构的一种调整目的是不改变软件可观测行为的前提下,提高其可理解性,降低修改成本
      • 重构(动词):使用一系列的重构手法,在不改变软件可观测行为的前提下,调整其结构
      • 重构原则:时刻保持软件可用:如果有人说他们的代码在重构过程中有一两天的时间不可用,基本上可以确定,他们在做的事情不是重构
    • “两顶帽子”:添加新功能、调整代码结构
      • 开发的时候自己可能经常变换帽子
    • 为何重构
      • 重构改进软件的设计:经常性的重构有助于代码维持自己该有的形态并消除重复代码
      • 重构使软件更容易理解:代码不只给计算机用,还给其他的维护者用,经常的重构可以让人更能看懂代码的含义
      • 重构帮助找到 bug:对代码进行重构,我就可以深入理解代码的所作所为,并立即把新的理解反映在代码当中。搞清楚程序结构的同时,我也验证了自己所做的一些假设,于是想不把bug揪出来都难。(以重构为驱动去理解代码?这里不是很理解
      • 重构提高编程速度:之前行业的陈规认为良好的设计必须在开始编程之前完成,因为开始编写代码后,设计就只会腐败,重构改变了这个图景。我们可以先做一个设计,然后随着需求的迭代不断改进它
    • 何时重构
      • 三次法则:事不过三,三则重构。第一次做某件事时只管去做;第二次做类似的事会产生反感,但无论如何还是可以去做;第三次再做类似的事,你就应该重构。
      • 预备性重构:让添加新功能更容易
      • 帮助理解的重构:使代码更易懂
      • 捡垃圾式重构:每个小步骤都不会破坏代码,就像捡垃圾一样,积少成多
    • 何时不应该重构
      • 不需要修改的代码:不需要修改的代码,就不需要重构它。只有当需要理解其工作原理时,对其进行重构才有价值 

第三章:代码坏味道

  • 总结:如何识别代码中不好的地方
    • 神秘命名:无法通过命名直观地知道变量或者方法的作用
    • 重复代码:设法将结构相似的代码合而为一,程序会变得更好。一旦有重复代码存在,阅读这些重复的代码时你就必须加倍仔细,留意其间细微的差异。如果要修改重复代码,你必须找出所有的副本来修改。如果重复的代码段位于同一个超类的不同子类中,可以使用函数上移来避免在两个子类之间互相调用。
    • 过长函数:函数的职责不够单一,导致直接违反开闭原则
      • 作者介绍了一条原则:每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中,并以其用途(而非实现手法)命名
    • 过长参数列表:如果可以向某个参数发起查询而获得另一个参数的值,那么就以查询取代参数,去掉这第二个参数
      • 使用类可以有效地缩短参数列表。如果多个函数有同样的几个参数,引入一个类就尤为有意义
    • 全局数据:全局数据代表全局任何一个地方都可以改变他而不受监控,一般需要通过封装变量的方式将这种全局的数据进行封装,通过方法进行改变
      • 封装变量的好处:1. 利于监控与定位问题 2. 如果这个变量需要跟一些协同变量同时改变,函数可以做到收口
    • 可变数据:尽量将查询和修改函数分开
    • 发散式变化:某个模块经常因为不同的原因在不同的方向上发生变化,这就意味着这个模块已经违反了单一职责原则,需要进行分割
    • 霰弹式修改:每次遇到某种变化,你必须在很多不同的类中进行小幅修改,这就说明你的模块拆分的过细
    • 依恋情结:一个函数跟另外的模块的函数或者数据交流格外频繁,远胜于自己所处模块内部的交流。应该将这个函数跟另外的模块放到一起
    • 数据泥团:如果你能在多个函数的参数中看到几个字段经常一起出现,这就是典型的数据泥团,应该将这些字段封装成类进行传递
      • 好处是可以将很多参数列表缩短,简化函数调用
      • 评判方法:删掉众多数据中的一项。如果这么做,其他数据不再有意义,这就是一个明确信号:你应该为它们产生一个新对象
    • 基本类型偏执:比如区号、血型等业务逻辑,不要单纯的用 string 去表示这种类型,可以通过封装对象的方式取代基本数据类型进行业务逻辑表达
      • 病症:
        • 不愿意创建对自己问题域有用的基本类型,如钱、坐标、范围等
        • 使用字符串做所有的事情
      • 解决:用对象取代基本类型,将原本单独存在的数据值替换为对象
    • 重复的 switch:用多态替代重复的 switch
    • 循环语句:作者提倡使用管道(比如 js 的 map filter等操作符)取代循环(但是我不认为循环就是个坏味道)
    • 夸夸其谈的通用性:即过度设计
    • 临时字段:特定情况临时加的
    • 过大的类:类的职责过度,需要进行拆分
    • 被拒绝的遗赠:如果拒绝父类的实现&接口,那继承父类就完全没有意义,不如通过以委托取代子类去代替继承关系
    • 注释:注释意味着这里的函数可以再次拆分成更小的函数 & 函数的命名可以再次优化。这里并不是说完全不可以写注释

第四章:构筑测试体系

  • 总结:要正确地进行重构,前提是得有一套稳固的测试集合
  • 自测case的一些原则
    • 让所有的测试都完全自动化,让它们自己检查测试结果
    • 一套测试就是一个强大的 bug 侦测器,能够大大缩减查找 bug 所需的时间
    • 总是确保测试case在不该通过时真的会失败
    • 频繁地运行测试,对于你正在处理的代码,与其对应的测试至少每隔几分钟就要运行一次,每天至少运行一遍所有的测试
    • 测试 case 不要求过度完美,编写未臻完善的测试并经常运行,好过对完美测试的无尽等待。
    • 将UI与业务逻辑隔离,这样才能写测试用例直接测逻辑部分
    • 考虑可能出错的边界,把测试火力集中到那里
      • 不断探索程序的错误边界反过来可以提高我们正向编程的能力
    • 不要幻想把所有场景都覆盖测试,只覆盖那些关键、容易出错的地方就够了,不然会因为工作量太大而气馁
    • 每当你收到一个 bug 时,请先写一个单元测试来暴露这个问题 

第五章:介绍重构名录

第六章:第一组重构

第七章:封装

重构改善既有代码的设计-学习(一):封装-CSDN博客

第八章:搬移特性

重构改善既有代码的设计-学习(二):搬移特性-CSDN博客

第九章:重新组织数据

重构改善既有代码的设计-学习(三):重新组织数据-CSDN博客

第十章:简化条件逻辑

重构改善既有代码的设计-学习(四):简化条件逻辑-CSDN博客

第十一章:重构API

重构改善既有代码的设计-学习(五):重构API-CSDN博客

第十二章:处理继承关系

重构改善既有代码的设计-学习(六):处理继承关系-CSDN博客

第1章 重构,第一个案例 1 1.1 起点 1 1.2 重构的第一步 7 1.3 分解并重组statement() 8 1.4 运用多态取代与价格相关的条件逻辑 34 1.5 结语 52 第2章 重构原则 53 2.1 何谓重构 53 2.2 为何重构 55 2.3 何时重构 57 2.4 怎么对经理说 60 2.5 重构的难题 62 2.6 重构设计 66 2.7 重构与性能 69 2.8 重构起源何处 71 第3章 代码的坏味道 75 3.1 Duplicated Code(重复代码) 76 3.2 Long Method(过长函数) 76 3.3 Large Class(过大的类) 78 3.4 Long Parameter List(过长参数列) 78 3.5 Divergent Change(发散式变化) 79 3.6 Shotgun Surgery(霰弹式修改) 80 3.7 Feature Envy(依恋情结) 80 3.8 Data Clumps(数据泥团) 81 3.9 Primitive Obsession(基本类型偏执) 81 3.10 Switch Statements(switch惊悚现身) 82 3.11 Parallel InheritanceHierarchies(平行继承体系) 83 3.12 Lazy Class(冗赘类) 83 3.13 Speculative Generality(夸夸其谈未来性) 83 3.14 Temporary Field(令人迷惑的暂时字段) 84 3.15 Message Chains(过度耦合的消息链) 84 3.16 Middle Man(中间人) 85 3.17 Inappropriate Intimacy(狎昵关系) 85 3.18 Alternative Classes with Different Interfaces(异曲同工的类) 85 3.19 Incomplete Library Class(不完美的库类) 86 3.20 Data Class(纯稚的数据类) 86 3.21 Refused Bequest(被拒绝的遗赠) 87 3.22 Comments(过多的注释) 87 第4章 构筑测试体系 89 4.1 自测试代码的价值 89 4.2 JUnit测试框架 91 4.3 添加更多测试 97 第5章 重构列表 103 5.1 重构的记录格式 103 5.2 寻找引用点 105 5.3 这些重构手法有多成熟 106 第6章 重新组织函数 109 6.1 Extract Method(提炼函数) 110 6.2 Inline Method(内联函数) 117 6.3 Inline Temp(内联临时变量) 119 6.4 Replace Temp with Query(以查询取代临时变量) 120 6.5 Introduce Explaining Variable(引入解释性变量) 124 6.6 Split Temporary Variable(分解临时变量) 128 6.7 Remove Assignments to Parameters(移除对参数的赋值) 131 6.8 Replace Method with Method Object(以函数对象取代函数) 135 6.9 Substitute Algorithm(替换算法) 139 第7章 在对象之间搬移特性 141 7.1 Move Method(搬移函数) 142 7.2 Move Field(搬移字段) 146 7.3 Extract Class(提炼类) 149 7.4 Inline Class(将类内联化) 154 7.5 Hide Delegate(隐藏“委托关系”) 157 7.6 Remove Middle Man(移除中间人) 160 7.7 Introduce Foreign Method(引入外加函数) 162 7.8 Introduce Local Extension(引入本地扩展) 164 第8章 重新组织数据 169 8.1 Self Encapsulate Field(自封装字段) 171 8.2 Replace Data Value with Object(以对象取代数据值) 175 8.3 Change Value to Reference(将值对象改为引用对象) 179 8.4 Change Reference to Value(将引用对象改为值对象) 183 8.5 Replace Array with Object(以对象取代数组) 186 8.6 Duplicate Observed Data(复制“被监视数据”) 189 8.7 Change Unidirectional Association to Bidirectional(将单向关联改为双向关联) 197 8.8 Change Bidirectional Association to Unidirectional(将双向关联改为单向关联) 200 8.9 Replace Magic Number with Symbolic Constant(以字面常量取代魔法数) 204 8.10 Encapsulate Field(封装字段) 206 8.11 Encapsulate Collection(封装集合) 208 8.12 Replace Record with Data Class(以数据类取代记录) 217 8.13 Replace Type Code with Class(以类取代类型码) 218 8.14 Replace Type Code with Subclasses(以子类取代类型码) 223 8.15 Replace Type Code with State/Strategy(以State/Strategy取代类型码) 227 8.16 Replace Subclass with Fields(以字段取代子类) 232 第9章 简化条件表达式 237 9.1 Decompose Conditional(分解条件表达式) 238 9.2 Consolidate Conditional Expression(合并条件表达式) 240 9.3 Consolidate Duplicate Conditional Fragments(合并重复的条件片段) 243 9.4 Remove Control Flag(移除控制标记) 245 9.5 Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件表达式) 250 9.6 Replace Conditional with Polymorphism(以多态取代条件表达式) 255 9.7 Introduce Null Object(引入Null对象) 260 9.8 Introduce Assertion(引入断言) 267 第10章 简化函数调用 271 10.1 Rename Method(函数改名) 273 10.2 Add Parameter(添加参数) 275 10.3 Remove Parameter(移除参数) 277 10.4 Separate Query from Modifier(将查询函数和修改函数分离) 279 10.5 Parameterize Method(令函数携带参数) 283 10.6 Replace Parameter with Explicit Methods(以明确函数取代参数) 285 10.7 Preserve Whole Object(保持对象完整) 288 10.8 Replace Parameter with Methods(以函数取代参数) 292 10.9 Introduce Parameter Object(引入参数对象) 295 10.10 Remove Setting Method(移除设值函数) 300 10.11 Hide Method(隐藏函数) 303 10.12 Replace Constructor with Factory Method(以工厂函数取代构造函数) 304 10.13 Encapsulate Downcast(封装向下转型) 308 10.14 Replace Error Code with Exception(以异常取代错误码) 310 10.15 Replace Exception with Test(以测试取代异常) 315 第11章 处理概括关系 319 11.1 Pull Up Field(字段上移) 320 11.2 Pull Up Method(函数上移) 322 11.3 Pull Up Constructor Body(构造函数本体上移) 325 11.4 Push Down Method(函数下移) 328 11.5 Push Down Field(字段下移) 329 11.6 Extract Subclass(提炼子类) 330 11.7 Extract Superclass(提炼超类) 336 11.8 Extract Interface(提炼接口) 341 11.9 Collapse Hierarchy(折叠继承体系) 344 11.10 Form Tem Plate Method(塑造模板函数) 345 11.11 Replace Inheritance with Delegation(以委托取代继承) 352 11.12 Replace Delegation with Inheritance(以继承取代委托) 355 第12章 大型重构 359 12.1 Tease Apart Inheritance(梳理并分解继承体系) 362 12.2 Convert Procedural Design to Objects(将过程化设计转化为对象设计) 368 12.3 Separate Domain from Presentation(将领域和表述/显示分离) 370 12.4 Extract Hierarchy(提炼继承体系) 375 第13章 重构,复用与现实 379 13.1 现实的检验 380 13.2 为什么开发者不愿意重构他们的程序 381 13.3 再论现实的检验 394 13.4 重构的资源和参考资料 394 13.5 从重构联想到软件复用和技术传播 395 13.6 小结 397 13.7 参考文献 397 第14章 重构工具 401 14.1 使用工具进行重构 401 14.2 重构工具的技术标准 403 14.3 重构工具的实用标准 405 14.4 小结 407 第15章 总结 409
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值