出版社: 人民邮电出版社
出品方: 异步图书
副标题: 改善既有代码的设计
原作名: Refactoring: Improving the Design of Existing Code,Second Edition
译者: 熊节 / 林从羽
出版年: 2019-3
页数: 422
定价: 168
装帧: 精装
ISBN: 9787115508645
内容简介 · · · · · ·
1. 世界级软件开发大师的不朽经典
2. 生动阐述重构原理和具体做法
3. 普通程序员进阶到编程高手必须修炼的秘笈
重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码。20 多年前,正是《重构:改善既有代码的设计》第1 版的出版,使重构终于从编程高手们的 小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分。如今,Martin Fowler 的《重构:改善既有代码的设计》一书已经成为全球有经验的程序员手中的利器,既可用来改善既有代码的设计、提升软件的可维护性,又可用于使既有代码更易理解、焕发出新的活力。
这本备受关注的第2 版在第1 版的基础上做了全面修订,反映了编程领域业已发生的许多变化。第2 版中介绍的重构列表更加内聚,并用JavaScript 语言重写了代码范例。此外,第2 版中还新增了与函数式编程相关的重构范例,旨在教...
1. 世界级软件开发大师的不朽经典
2. 生动阐述重构原理和具体做法
3. 普通程序员进阶到编程高手必须修炼的秘笈
重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码。20 多年前,正是《重构:改善既有代码的设计》第1 版的出版,使重构终于从编程高手们的 小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分。如今,Martin Fowler 的《重构:改善既有代码的设计》一书已经成为全球有经验的程序员手中的利器,既可用来改善既有代码的设计、提升软件的可维护性,又可用于使既有代码更易理解、焕发出新的活力。
这本备受关注的第2 版在第1 版的基础上做了全面修订,反映了编程领域业已发生的许多变化。第2 版中介绍的重构列表更加内聚,并用JavaScript 语言重写了代码范例。此外,第2 版中还新增了与函数式编程相关的重构范例,旨在教会读者如何在没有类的环境下开展重构。
新版沿袭了第1 版的结构,依次解释什么是重构,为什么要重构,如何通过“坏味道”识别出需要重构的代码,以及如何在实践中成功实施重构(无论用的是什么编程语言)。
本书将帮助读者:
● 理解重构的过程和重构的基本原则;
● 快速有效地应用各种重构手法,提升程序的表达力和可维护性;
● 识别代码中能指示出需要重构的地方的“坏味道”;
● 深入了解各种重构手法,每个手法都包含解释、动机、做法和范例4 个部分;
● 构建稳固的测试,以支持重构工作的开展;
● 理解重构过程的权衡取舍以及重构存在的挑战等。
本书凝聚了软件开发社区专家多年摸索而获得的宝贵经验,书中所蕴涵的思想和精华,值得反复咀嚼,而且往往能够常读常新。
作者简介 · · · · · ·
作者简介
马丁·福勒(Martin Fowler)
世界软件开发大师,ThoughtWorks的首席科学家。他是一位作家、演说者、咨询师和泛软件开发领域的意见领袖。他致力于改善企业级的软件设计,对优秀的设计以及支撑优秀设计的工程实践孜孜以求。他在重构、面向对象分析设计、模式、XP和UML等领域都有卓越贡献。著有《重构》《分析模式》《领域特定语言》等经典著作。
译者简介
熊节
在IT行业已经打拼了18年,在金融、零售、政府、电信、制造业等行业的信息化建设方面有着丰富经验,是中国IT业敏捷浪潮的领军人物。熊节拥有利物浦大学MBA学位。
林从羽
ThoughtWorks软件开发工程师,曾服务于国内外多家大型企业,致力于为团队更快更好地交付可 工作的软件。拥抱敏捷精神,TDD爱好者,纯键盘工作者。
目录 · · · · · ·
1.1 起点 1
1.2 对此起始程序的评价 3
1.3 重构的第一步 5
1.4 分解statement函数 6
1.5 进展:大量嵌套函数 22
· · · · · · (更多)
1.1 起点 1
1.2 对此起始程序的评价 3
1.3 重构的第一步 5
1.4 分解statement函数 6
1.5 进展:大量嵌套函数 22
1.6 拆分计算阶段与格式化阶段 24
1.7 进展:分离到两个文件(和两个阶段) 31
1.8 按类型重组计算过程 34
1.9 进展:使用多态计算器来提供数据 41
1.10 结语 43
第2章 重构的原则 45
2.1 何谓重构 45
2.2 两顶帽子 46
2.3 为何重构 47
2.4 何时重构 50
2.5 重构的挑战 55
2.6 重构、架构和YAGNI 62
2.7 重构与软件开发过程 63
2.8 重构与性能 64
2.9 重构起源何处 67
2.10 自动化重构 68
2.11 延展阅读 70
第3章 代码的坏味道 71
3.1 神秘命名(Mysterious Name) 72
3.2 重复代码(Duplicated Code) 72
3.3 过长函数(Long Function) 73
3.4 过长参数列表(Long Parameter List) 74
3.5 全局数据(Global Data) 74
3.6 可变数据(Mutable Data) 75
3.7 发散式变化(Divergent Change) 76
3.8 霰弹式修改(Shotgun Surgery) 76
3.9 依恋情结(Feature Envy) 77
3.10 数据泥团(Data Clumps) 78
3.11 基本类型偏执(Primitive Obsession) 78
3.12 重复的switch(Repeated Switches) 79
3.13 循环语句(Loops) 79
3.14 冗赘的元素(Lazy Element) 80
3.15 夸夸其谈通用性(Speculative Generality) 80
3.16 临时字段(Temporary Field) 80
3.17 过长的消息链(Message Chains) 81
3.18 中间人(Middle Man) 81
3.19 内幕交易(Insider Trading) 82
3.20 过大的类(Large Class) 82
3.21 异曲同工的类(Alternative Classes with Different Interfaces) 83
3.22 纯数据类(Data Class) 83
3.23 被拒绝的遗赠(Refused Bequest) 83
3.24 注释(Comments) 84
第4章 构筑测试体系 85
4.1 自测试代码的价值 85
4.2 待测的示例代码 87
4.3 第一个测试 90
4.4 再添加一个测试 93
4.5 修改测试夹具 95
4.6 探测边界条件 96
4.7 测试远不止如此 99
第5章 介绍重构名录 101
5.1 重构的记录格式 101
5.2 挑选重构的依据 102
第6章 第一组重构 105
6.1 提炼函数(Extract Function) 106
6.2 内联函数(Inline Function) 115
6.3 提炼变量(Extract Variable) 119
6.4 内联变量(Inline Variable) 123
6.5 改变函数声明(Change Function Declaration) 124
6.6 封装变量(Encapsulate Variable) 132
6.7 变量改名(Rename Variable) 137
6.8 引入参数对象(Introduce Parameter Object) 140
6.9 函数组合成类(Combine Functions into Class) 144
6.10 函数组合成变换(Combine Functions into Transform) 149
6.11 拆分阶段(Split Phase) 154
第7章 封装 161
7.1 封装记录(Encapsulate Record) 162
7.2 封装集合(Encapsulate Collection) 170
7.3 以对象取代基本类型(Replace Primitive with Object) 174
7.4 以查询取代临时变量(Replace Temp with Query) 178
7.5 提炼类(Extract Class) 182
7.6 内联类(Inline Class) 186
7.7 隐藏委托关系(Hide Delegate) 189
7.8 移除中间人(Remove Middle Man) 192
7.9 替换算法(Substitute Algorithm) 195
第8章 搬移特性 197
8.1 搬移函数 198
8.2 搬移字段(Move Field) 207
8.3 搬移语句到函数(Move Statements into Function) 213
8.4 搬移语句到调用者(Move Statements to Callers) 217
8.5 以函数调用取代内联代码(Replace Inline Code with Function Call) 222
8.6 移动语句(Slide Statements) 223
8.7 拆分循环(Split Loop) 227
8.8 以管道取代循环(Replace Loop with Pipeline) 231
8.9 移除死代码(Remove Dead Code) 237
第9章 重新组织数据 239
9.1 拆分变量(Split Variable) 240
9.2 字段改名(Rename Field) 244
9.3 以查询取代派生变量(Replace Derived Variable with Query) 248
9.4 将引用对象改为值对象(Change Reference to Value) 252
9.5 将值对象改为引用对象(Change Value to Reference) 256
第10章 简化条件逻辑 259
10.1 分解条件表达式(Decompose Conditional) 260
10.2 合并条件表达式(Consolidate Conditional Expression) 263
10.3 以卫语句取代嵌套条件表达式(Replace Nested Conditional with Guard Clauses) 266
10.4 以多态取代条件表达式(Replace Conditional with Polymorphism) 272
10.5 引入特例(Introduce Special Case) 289
10.6 引入断言(Introduce Assertion) 302
第11章 重构API 305
11.1 将查询函数和修改函数分离(Separate Query from Modifier) 306
11.2 函数参数化(Parameterize Function) 310
11.3 移除标记参数(Remove Flag Argument) 314
11.4 保持对象完整(Preserve Whole Object) 319
11.5 以查询取代参数(Replace Parameter with Query) 324
11.6 以参数取代查询(Replace Query with Parameter) 327
11.7 移除设值函数(Remove Setting Method) 331
11.8 以工厂函数取代构造函数(Replace Constructor with Factory Function) 334
11.9 以命令取代函数(Replace Function with Command) 337
11.10 以函数取代命令(Replace Command with Function) 344
第12章 处理继承关系 349
12.1 函数上移(Pull Up Method) 350
12.2 字段上移(Pull Up Field) 353
12.3 构造函数本体上移(Pull Up Constructor Body) 355
12.4 函数下移(Push Down Method) 359
12.5 字段下移(Push Down Field) 361
12.6 以子类取代类型码(Replace Type Code with Subclasses) 362
12.7 移除子类(Remove Subclass) 369
12.8 提炼超类(Extract Superclass) 375
12.9 折叠继承体系(Collapse Hierarchy) 380
12.10 以委托取代子类(Replace Subclass with Delegate) 381
12.11 以委托取代超类(Replace Superclass with Delegate) 399
参考文献 405
索引 409
· · · · · · (收起)
原文摘录 · · · · · · ( 全部 )
-
to make the software easier to understand and modify. (查看原文) —— 引自第44页 -
refactoring does not change the observable behavior of the software Why Should You Refactor? Refactoring Improves the Design of Software Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster 即使在开发过程中,当你发现重复或相似的代码时,也应该立刻重构;当变化发生时,如果该变化影响不止一处,重构就应该粉墨登场。经常的重构可以保证代码常拭常新,如利刃一般锋利。“不要容忍破窗户” 如果两个或更多的地方实现同一职责,则改变时会带来麻烦。所以要遵循DRY原则,单一职责。 When Should You Refactor? The Rule of Three(Three strikes and you refactor) Refactor When You Add Function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review The most common time to refactor is when I want to add a new feature to some software. Reasons:1.refactoring helps me understand some code I need to modify.2.another driver of refactoring is a design that does not help me add a fe... (查看原文) —— 引自第44页
> 全部原文摘录
喜欢读"重构(第2版)全彩精装版"的人也喜欢 · · · · · ·
重构(第2版)全彩精装版的话题 · · · · · · ( 全部 条 )



重构(第2版)全彩精装版的书评 · · · · · · ( 全部 130 条 )
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 ...2020-12-18 10:05
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 这样的特性分支有其缺点。在隔离的分支上工作得越久,将完成的工作集成(Integrate)回主线就会越困难。为了减轻集成的痛苦,大多数人的办法是频繁地从主线合并(merge)或者变基( rebase)到分支。但如果有几个人同时在各自的特性分支上工作,这个办法并不能真正解決问题,因为合并与集成是两回事。如果我从主线合并到我的分支,这只是一个单向的代码移动一一我的分支发生了修改,但主线并没有。而“集成”是一个双向的过程:不仅要把主线的修改拉(pull)到我的分支上,而且要把我这里修改的结果推(push)回到主线上,两边都会发生修改。假如另一名程序员 Rachel正在她的分支上开发,我是看不见她的修改的,直到她将自己的修改与主线集成;此时我就必须把她的修改合并到我的特性分支,这可能需要相当的工作量。其中困难的部分是处理语义变化。现代版本控制系统都能很好地合并程序文本的复杂修改,但对于代码的语义它们一无所知。如果我修改了一个函数的名字,版本控制工具可以很轻松地将我的修改与 Rachel的代码集成。但如果在集成之前,她在自已的分支里新添调用了这个被我改名的函数集成之后的代码就会被破坏。 引自 2.5 重构的挑战 55 这学期和小组队友用git协同开发安卓app的时候的确很被这点困扰。之前没意识到这一点,队友也觉得应该在自己的分支上把功能写完再并入master,导致每次把自己的分支merge到master上的时候总要花一些时间专门处理merge conflicts。
回应 2020-12-18 10:05 -
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
开展高效有序的重构,关键的心得是:小的步子可以更快前进,请保持代码永远处于可工作状态,小步修改累积起来也能大大改善系统的设计。这几点请君牢记,其余的我已无需多言。 个人心得:小步改动不仅适用于重构代码,也适用于构建代码项目。小步改动、小步测试,充分利用多分支版本控制系统的回退、分支功能,commit -m的注释也要写清楚,包括但不限于改动的类型、对什么文件做了改动(虽然可以用git diff查看两个commit的差别...2020-12-17 13:58
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一...2020-08-26 19:59
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一串字符。一个体面的类型,至少能包含一致的显示逻辑,在用户界面上需要显示时可以使用。“用字符串来代表类似这样的数据”是如此常见的臭味,以至于人们给这类变量专门起了一个名字,叫它们“类字符串类型”( stringly typed)变量。 引自 3.11 基本类型偏执(Primitive Obsession) 78 《算法》里把图这个数据类型做成了相对复杂的类(比如增加邻接边数量这一成员变量)。一开始我还对一些看似多余的逻辑感到烦躁,后来看到拓扑排序的bfs算法时发现这种做法省了一部分算法实现的代码量。当然计算钱和物理量时在这方面欠缺考虑导致的后果自然更严重。
回应 2020-08-26 19:59
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 ...2020-12-18 10:05
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 这样的特性分支有其缺点。在隔离的分支上工作得越久,将完成的工作集成(Integrate)回主线就会越困难。为了减轻集成的痛苦,大多数人的办法是频繁地从主线合并(merge)或者变基( rebase)到分支。但如果有几个人同时在各自的特性分支上工作,这个办法并不能真正解決问题,因为合并与集成是两回事。如果我从主线合并到我的分支,这只是一个单向的代码移动一一我的分支发生了修改,但主线并没有。而“集成”是一个双向的过程:不仅要把主线的修改拉(pull)到我的分支上,而且要把我这里修改的结果推(push)回到主线上,两边都会发生修改。假如另一名程序员 Rachel正在她的分支上开发,我是看不见她的修改的,直到她将自己的修改与主线集成;此时我就必须把她的修改合并到我的特性分支,这可能需要相当的工作量。其中困难的部分是处理语义变化。现代版本控制系统都能很好地合并程序文本的复杂修改,但对于代码的语义它们一无所知。如果我修改了一个函数的名字,版本控制工具可以很轻松地将我的修改与 Rachel的代码集成。但如果在集成之前,她在自已的分支里新添调用了这个被我改名的函数集成之后的代码就会被破坏。 引自 2.5 重构的挑战 55 这学期和小组队友用git协同开发安卓app的时候的确很被这点困扰。之前没意识到这一点,队友也觉得应该在自己的分支上把功能写完再并入master,导致每次把自己的分支merge到master上的时候总要花一些时间专门处理merge conflicts。
回应 2020-12-18 10:05 -
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
开展高效有序的重构,关键的心得是:小的步子可以更快前进,请保持代码永远处于可工作状态,小步修改累积起来也能大大改善系统的设计。这几点请君牢记,其余的我已无需多言。 个人心得:小步改动不仅适用于重构代码,也适用于构建代码项目。小步改动、小步测试,充分利用多分支版本控制系统的回退、分支功能,commit -m的注释也要写清楚,包括但不限于改动的类型、对什么文件做了改动(虽然可以用git diff查看两个commit的差别...2020-12-17 13:58
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一...2020-08-26 19:59
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一串字符。一个体面的类型,至少能包含一致的显示逻辑,在用户界面上需要显示时可以使用。“用字符串来代表类似这样的数据”是如此常见的臭味,以至于人们给这类变量专门起了一个名字,叫它们“类字符串类型”( stringly typed)变量。 引自 3.11 基本类型偏执(Primitive Obsession) 78 《算法》里把图这个数据类型做成了相对复杂的类(比如增加邻接边数量这一成员变量)。一开始我还对一些看似多余的逻辑感到烦躁,后来看到拓扑排序的bfs算法时发现这种做法省了一部分算法实现的代码量。当然计算钱和物理量时在这方面欠缺考虑导致的后果自然更严重。
回应 2020-08-26 19:59
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 ...2020-12-18 10:05
很多团队采用这样的版本控制实践:每个团队成员各自在代码库的一条分支上工作,进行相当大量的开发之后,オ把各自的修改合并回主线分支(这条分支通常叫master或trunk),从而与整个团队分享。常见的做法是在分支上开发完整的功能,直到功能可以发布到生产环境,才把该分支合并回主线。这种做法的拥趸声称,这样能保持主线不受尚未完成的代码侵扰,能保留清晰的功能添加的版本记录,并且在某个功能出问题时能容易地撤销修改。 这样的特性分支有其缺点。在隔离的分支上工作得越久,将完成的工作集成(Integrate)回主线就会越困难。为了减轻集成的痛苦,大多数人的办法是频繁地从主线合并(merge)或者变基( rebase)到分支。但如果有几个人同时在各自的特性分支上工作,这个办法并不能真正解決问题,因为合并与集成是两回事。如果我从主线合并到我的分支,这只是一个单向的代码移动一一我的分支发生了修改,但主线并没有。而“集成”是一个双向的过程:不仅要把主线的修改拉(pull)到我的分支上,而且要把我这里修改的结果推(push)回到主线上,两边都会发生修改。假如另一名程序员 Rachel正在她的分支上开发,我是看不见她的修改的,直到她将自己的修改与主线集成;此时我就必须把她的修改合并到我的特性分支,这可能需要相当的工作量。其中困难的部分是处理语义变化。现代版本控制系统都能很好地合并程序文本的复杂修改,但对于代码的语义它们一无所知。如果我修改了一个函数的名字,版本控制工具可以很轻松地将我的修改与 Rachel的代码集成。但如果在集成之前,她在自已的分支里新添调用了这个被我改名的函数集成之后的代码就会被破坏。 引自 2.5 重构的挑战 55 这学期和小组队友用git协同开发安卓app的时候的确很被这点困扰。之前没意识到这一点,队友也觉得应该在自己的分支上把功能写完再并入master,导致每次把自己的分支merge到master上的时候总要花一些时间专门处理merge conflicts。
回应 2020-12-18 10:05 -
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
开展高效有序的重构,关键的心得是:小的步子可以更快前进,请保持代码永远处于可工作状态,小步修改累积起来也能大大改善系统的设计。这几点请君牢记,其余的我已无需多言。 个人心得:小步改动不仅适用于重构代码,也适用于构建代码项目。小步改动、小步测试,充分利用多分支版本控制系统的回退、分支功能,commit -m的注释也要写清楚,包括但不限于改动的类型、对什么文件做了改动(虽然可以用git diff查看两个commit的差别...2020-12-17 13:58
-
夏夜寂寞轻注销 (だって、いずれわかるものだけさ)
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一...2020-08-26 19:59
大多数编程环境都大量使用基本类型,即整数、浮点数和字符串等。一些库会引入一些小对象,如日期。但我们发现一个很有趣的现象:很多程序员不愿意创建对自己的问题域有用的基本类型,如钱、坐标、范围等。于是,我们看到了把钱当普通数字来计算的情况、计算物理量时无视单位(如把英寸与毫米相加)的情况以及大量类似if (a < upper && a >lower)这样的代码。 字符串是这种坏味道的最佳培养皿,比如,电话号码不只是一串字符。一个体面的类型,至少能包含一致的显示逻辑,在用户界面上需要显示时可以使用。“用字符串来代表类似这样的数据”是如此常见的臭味,以至于人们给这类变量专门起了一个名字,叫它们“类字符串类型”( stringly typed)变量。 引自 3.11 基本类型偏执(Primitive Obsession) 78 《算法》里把图这个数据类型做成了相对复杂的类(比如增加邻接边数量这一成员变量)。一开始我还对一些看似多余的逻辑感到烦躁,后来看到拓扑排序的bfs算法时发现这种做法省了一部分算法实现的代码量。当然计算钱和物理量时在这方面欠缺考虑导致的后果自然更严重。
回应 2020-08-26 19:59
论坛 · · · · · ·
求此书pdf | 来自后知后觉 | 2020-03-01 | |
<重构 改善既有代码的设计 第2版>读后的个人感受 | 来自Leo | 2019-03-12 | |
重构(第2版)阅读感悟 | 来自Datura | 2019-03-12 |
这本书的其他版本 · · · · · · ( 全部12 )
-
中国电力出版社 (2003)9.0分 2836人读过
-
Addison-Wesley Professional (1999)9.1分 247人读过
-
人民邮电出版社 (2010)9.0分 2065人读过
-
中国电力出版社 (2003)9.1分 310人读过
以下书单推荐 · · · · · · ( 全部 )
谁读这本书?
二手市场
订阅关于重构(第2版)全彩精装版的评论:
feed: rss 2.0
3 有用 陆谲 2019-11-26
做了简单的脑图,感兴趣移步这里观看 https://s33h0w.me/2019/11/12/重构第二版思维导图/
7 有用 Zoom.Quiet 2020-02-29
是也乎,( ̄▽ ̄) 前后两个版本都看过... 还找来了原版的对比看,,,, 金句很多, 但是, 核心就一句话: 如果你有空的话... 所以, 基本上, 除非团队愿意为技术债务专门给预算来折腾, 否则...宁可在第一次编写时, 就隐式的完成一系列重构吧...
0 有用 王悟空 2020-03-16
读完了原则部分,60%吧,感觉后面代码部分就是把idea的重构功能摊开讲了一遍...大概这就是老书的局限性吧。
0 有用 逃脱矩阵 2020-01-15
主要就是讲封装函数,封装类,看一遍还是有收获
1 有用 旸谷 2019-12-25
经典计算机图书20年后的新版,从第1版的Java语言改为第2版的JavaScript,门槛应该算是降低了的。翻译质量很值得肯定。对阅读体验要求高的,可以选这个全彩精装版,代码着色还是看起来比较舒适的。
0 有用 胡椒烩黑椒 2021-03-04
看完极客时间王争的「设计模式」再看的,感觉其中有些内容都约定俗成了吧。
0 有用 灯 2021-02-20
还留在有概念有意识但理解不深的阶段
0 有用 卖达芬奇的。 2021-02-20
中规中矩吧,把一些常见的场景和应对方式大致列举了。
0 有用 DemacL 2021-02-17
编程的思想和思维方式,值得反复读
0 有用 大怪兽 2021-02-15
读来确实矛盾,一方面因为没有太多场合允许做精深的重构,很多业务代码甚至是写完就放在那里了。另一方面,重构列表中有大约三分之一的方法个人感觉都是普通工程师的应知应会了。最后,对于很多写业务的前端开发来说,对于类对于继承对于面向接口理解的程度上根本不足以思考重构