《重构》章节试读

《重构》的笔记-第89页 - 4.1 自测试代码的价值

如果认真观察程序员把最多时间耗在哪里，你就会发现，编写代码其实只占非常小的一部分。有些时间用来决定下一步干什么，另一些时间花在设计上，最多的时间则是用来调试。程序员大部分时间是在调试，所以，良好的测试用例是非常有效的。

《重构》的笔记-第69页

教训：哪怕你完全了解系统，也请实际度量它的性能，不要臆测。臆测会让你学到一些东西，但是十有八九你是错的。

《重构》的笔记-第98页

编写未臻完善的测试代码并实际运行，好过对完美测试的等待
其实，对于敏捷开发而言，原则就是从部分功能开始动手，完善，直至可以运行，接着下一个迭代。之前的瀑布式模型则是追求整体的完成……

《重构》的笔记-第61页 - 间接层与重构

间接层的价值
1.允许逻辑共享
2.分开解释意图和实现
3.隔离变化
4.封装条件逻辑

《重构》的笔记-第73页

p1
没有单元测试以及回归测试
重构就不是那么美丽
p29
Extract Method
提炼函数
Move Method
搬移函数
到底是在哪个类中或模块中?
函数到底是操作自己所在的类或模块多，还是别的类或模块多?
(p34页的观点
谁是容易产生变化的,就放在谁里面, 避免当类或模块产生变化时对外界产生大的影响,内部消化:))
Replace Temp With Query
去除临时变量
不要担心query method的性能代价
重构是重构
优化是优化
p39
state与strategy的区别在于如何抽象
就书中的例子来说
是想以不同的计费类型这个Method来区分对象，这句话换个说法就是同样的对象想要有不同的某个行为的策略，使用Strategy
想以整个对象来区分,则是State
Replace Type Code With State/Strategy
State与Strategy两者在结构上有很多相似的地方
Self Encapsulate Field
对于内部field的Setter和Getter的封装，这是仁者见仁智者见智的事情
就象virtual function不应该直接对外，而应该包一层non virtual function，这些行为都没有绝对的正确的准则
Replace Conditional with Polymorphism
利用继承来去掉switch
第2章的内容其实很多都是在工作中能够领悟的
仅引用书中的一句话来形容重构的时机
事不过三,三则重构

《重构》的笔记-第1页

测试笔记

《重构》的笔记-第77页 - 代码的坏味道

“间接层”带来的全部利益——解释能力、共享能力、选择能力

《重构》的笔记-第60页

我们希望程序可以
1）容易阅读
2） 所有逻辑都只在唯一地点指定
3）新的改动不会危及现有行为
4） 尽可能简单表达条件逻辑

《重构》的笔记-第38页 - 第一章 重构,第一个案例

一部影片可以在生命周期内修改自己的分类,一个对象却不能在生命周期内修改自己所属的类.
这段话不是很理解,在C++里面是可以通过引用或指针来实现多态,难道Java没有类似的概念
吗?
这里就已继承的方式表现不同的影片类型,然后在Customer类中保存影片的引用,不就可以实现不同的电影采用不同计价方式吗?为啥搞这么负载,还通过一个Price类来实现.

《重构》的笔记-第98页 - 4.3 添加更多的测试

编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。

《重构》的笔记-第77页 - 代码的坏味道

3.2 Long Method（过长函数）
如何确定该提炼哪一段代码呢？一个很好的技巧是：寻找注释。它们通常能指出代码用途和实现手法之间的语义距离。如果代码前方有一行注释，就是在提醒你：可以将这段代码替换成一个函数，而且可以在注释的基础上给这个函数命名。就算只有一行代码，如果它需要以注释来说明，那也值得将它提炼到独立函数去。

《重构》的笔记-第55页

如果消除重复代码，你就可以确定所有事情和行为在代码中指表述一次，这正是优秀设计的根本

《重构》的笔记-第6页 - 重构，第一个案例

一、碰到方法内容太长的时候，肯定是需要重构的。
1、内容太长，程序员难以找到修改点，所以程序员容易引入BUG。
2、对于原始作者来说，需要写一个长方法时，思路容易扯的太广，从而失去了关注点。如果代码很短，只关注 一个点的时候，你考虑这个点就比较全面周到。bug也会在眼前无处可藏。
3、虽然代码是给机器运行的，客户也看不到代码。从这个方面来说，代码只要能实现功能即可。但代码最终还是要给人修改的。重构就是如何保证修改的人最少犯错，最少引入新的bug，最快理解代码的意思。

《重构》的笔记-第86页 - 3.20 Data Class(纯稚的数据类)

与《Clean Code》 Chapter 6:Objects and Data Structures 内容有分歧。
Clean Code 表示数据类和Object( 成员变量为private且不暴露getter,setter的类)只能二选一，要么是纯洁的数据类，要么是纯洁的Object，用数据类可以提供新增业务逻辑的灵活性，Object提供新增数据类型的灵活性。如果混合起来恐怕两种优势都混没了。
我觉得《Clean code》Chapter 6更有说服性。

《重构》的笔记-第78页 - 3. 4 过长参数列

对象技术改变了这一情况：如果你手上没有所需的东西，总可以叫另一个对象给你。传递参数，尽可能用对象而不是一对单个的参数。

《重构》的笔记-第69页 - 2.7 重构与性能

编写快速程序的三种方法：
1. 时间预算法。
2. 持续关注法。
3. 度量并寻找代码中的热点并优化之。
短期内，重构的确可能使软件变慢。但是它使优化阶段的软件性能调整更加容易，最终还是会得到好的效果。

《重构》的笔记-第52页 - 1.5 结语

这个例子给我们最大的启发是重构的节奏：测试，小修改，测试，小修改，测试，小修改。。。。。。正是这种节奏让重构得以快速而安全地前进。

《重构》的笔记-第79页

针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个类的所有内容都应该反应此变化。

《重构》的笔记-第11页 - Refactoring, a First Example

重構前一定要寫好單元測試。（我從未寫過測試…）
以下的每一句摘抄都值得仔細斟酌。
Any non-modified variable I can pass in as a parameter. Modified variables need more care.
Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Once I've made a change I compile and test to make sure I haven't broken anything.
The rhythm of refactoring: test, small change, test, small change, test small change. It is that rhythm that allows refactoring to move quickly and safely.

《重构》的笔记-第86页 - 3.20 Data Class 纯稚的数据类

所谓Data Class 是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。这样的类只是一种不会说话的数据容器，它们几乎一定被其他类过分细琐地操控着。如果要让这些数据类成熟起来，一定要让它们承担一些责任。

《重构》的笔记-第88页 - 3.22 comments

当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。

《重构》的笔记-第97页

每当你接获臭虫提报(Bug report)，请先撰写一个单元测试来揭发这个臭虫。心得：能编写单元测试来揭发这个bug，好处在于：
1、界定问题范围；
2、解决bug后可以重新测试；
3、更全面的考虑bug发生的原因，并弥补可能存在的其他漏洞

《重构》的笔记-第59页

换句话说，我会和某个团队进行设计复审，而和单个复审者进行代码复审。
design review with a team, code review with a buddy.

《重构》的笔记-第62页

重构 vs 推测性设计

《重构》的笔记-第52页 - 重构，第一个案例

每当我要进行重构的时候，第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。
重构的节奏：测试、小修改、测试、小修改、测试、小修改……正是这种节奏让重构得以快速而安全地进行。
感想：重构来源自编程者对于面向对象编程的理解，对于程序可复用，灵活性的理解。是自然而然的一件事，作者将这件事总结并概念化作记录。
当前自己效率卡在了重构的第一步，没有可靠的自动化测试工具。这是下一步要做的。

《重构》的笔记-第7页 - 重构，第一个案例

重构第一步：建立一组可靠的测试环境。

《重构》的笔记-第58页 - 重构原则

三次法则
Don Roberts给了我一条准则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。
☆ 事不过三，三则重构。

《重构》的笔记-第53页 - 重构 第一个案例

看完第一章，很喜欢这种开门见山写书的方式，没有那多啰哩啰唆的背景介绍，直接切入主题，从实例讲起，循序渐渐，与设计模式书籍配合一起看更好

《重构》的笔记-第34页 - 重构，第一个案例

运用多态取代复杂的条件逻辑，多分支逻辑判定代码，这个原则用的非常广泛

《重构》的笔记-第54页

添加功能是不要重构；
重构是不要添加功能；
除非发现先前有遗漏的东西。

《重构》的笔记-第90页 - 4.1 自测试代码的价值

一套测试就是一个强大的bug侦查器，能够大大缩减查找bug所需要的时间。

《重构》的笔记-第53页 - 2.1 何谓重构

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。简单的说，就是不改变对外形式的内部调整。
目的是：提高可理解性，降低修改成本。

《重构》的笔记-第15页 - 1.3 分解并重组 statement()

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。

《重构》的笔记-第60页 - 重构原则

说的很好

《重构》的笔记-第1页 - 1

重构：对软件结构内部的一种调整，使在不改变软件可观察行为的前提下，提高其可理解性，降低修改成本
重构和添加新功能：分清处在何种状态。
为何重构？
>改进软件设计
>使软件更容易理解
>帮你找到bug
>提高编程速度
何时重构？
>三次法则：事不过三，三则重构
>添加新功能时重构
>修补错误时重构
>复审代码时重构
重构的难题？
>数据库(数据迁移，结构改变)
>修改接口
何时不该重构？
>代码测试大段错误，无法运行(还不如重写)
>项目接近最后期限
编程中的坏味道检查表(可能需要重构的检查表)?
Duplicated Code :重复代码
Long Method:过长函数
Large Class:过大的类
Long Parameter List:过长参数列
Divergent Change:发散式变化-->一个类受多种变化影响
Shotgun Surgery:散弹式修改-->一种变化引发多个类的相应修改
Feature Envy:依恋情绪--> 将总是一起变化的东西放到一块
Data Clumps：数据泥团-->很多地方都能看到的相同的数据项，提取到一块
Primitive Obsession:基本类型偏执 -->考虑封装对象
Switch Statements: ---> 考虑使用多态
Parallel Inheritance Hierarchies :平行继承体系-->Shotgun Surgery 特殊情况
Lazy Class:冗赘类 -->如果某些子类没有做足够的工作，去掉他们
Speculative Generality:夸夸其谈未来性
Temporary Field:令人迷惑的暂时字段
Message Chains:过度耦合的消息链
Middle Man:中间人，委托..
Inappropriate Intimacy:狎昵关系 -->关系过于亲密
Alternative Classes WithDifferent Interfaces：异曲同工的类
Incomplete Library Class:不完美的库类
Data Class:纯粹的数据类
Refused Bequest:被拒绝的遗赠
Comments:过多的注释
重构的记录格式?
名称：
概要：
动机：
做法：
范例：
重构清单：
-------------------------------------------------------------------------------------------------------------
方法提取：
Extract Method(提取函数):
Inline Method(内联函数):在函数调用点插入本体，然后移除该函数
Inline Temp(内联临时变量):将所有对该变量的引用动作替换为对它赋值的那个表达式自身
Replace Temp with Query(以查询取代临时变量)
Introduce Explaining Variable(引入解释性变量):将复杂表达式或其中一部分的结果放进一个临时变量，以此变量名称来解释表达式用途
Split Temporary Variable(分解临时变量)：针对每次赋值，创造一个独立、对应的临时变量
Remove Assignments to parameters(移除对参数的赋值):以一个临时变量取代该参数的位置
::::Java使用按值传递的函数调用方式
Replace Method with Method Object(以函数对象取代函数):将这个函数放进一个单独对象中，如果一来局部变量就成了对象内的字段，然后你可以在同一个对象中将这个大型函数分解为多个小型函数i
Substitute Algorithm(替换算法):将函数本体替换为另一个算法
-------------------------------------------------------------------------------------------------------------在类之间搬移特性：
Move Method(搬移函数)：在该函数最常引用的类中建立一个有着类似行为的新函数，将旧函数变成一个单纯的委托函数，或是将旧函数完全移除 "这个函数与哪个对象的交流比较多决定其移动路径"
Move Field(搬移字段):在目标类新建一个字段，修改源字段的所有用户，令它们改用新字段
Extract Class(提炼类):建立一个新类，将相关的字段和函数从旧类搬移到新类
Inline Class(将类内联化)：将这个类的所有特性搬移到另一个类中，然后移除原类
Hide Delegate(隐藏委托关系):在服务类上建立客户所需的所有函数，用以隐藏委托关系
Remove Middle Man(移除中间人):让客户直接调用委托类
Introduce Foreign Method(引入外加函数):在客户类中建立一个函数，并以第一参数形式传入一个服务类实例
Introduce Local Extension(引入本地扩展):建立一个新类，使它包含这些额外函数，让这个扩展品成为源类的子类或包装类

《重构》的笔记-第77页 - 3.2 过长函数

每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现方法）命令。

《重构》的笔记-第57页 - 2.2 为何重构

这让我想起来 Kent Beck 经常形容自己的一句话：“我不是个伟大的程序员，我只是个有着一些优秀习惯的好程序员。”

《重构》的笔记-第52页 - 第一章

开篇不错。

《重构》的笔记-第15页

更改变量名称是值得的行为吗？绝对值得。好的代码应该清楚表达出自己的功能，变量名称是代码清晰的关键。如果为了提高代码的清晰度，需要修改某些东西的名字，那么就大胆去做吧。

《重构》的笔记-第80页 - 3.6 散弹式修改

Divergent Change 是指＂一个类受多种变化的影响＂，Shotgun Surgery则是指＂一种变化引发多个类相应修改＂。这两种情况下你都会希望整理代码

《重构》的笔记-第77页

我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。

《重构》的笔记-第90页 - 4.1 自测试代码的价值

确保所有测试都完全自动化，让它们检查自己的测试结果。

《重构》的笔记-第1页

1。重构不是重写，不需要停下来专门花时间。
2。重构是为了保持程序的可读性/减少重复性，使其保持生命力。
3。重构需要辅以自动化测试工具。
4。重构需要小步实施，每次实施辅以自动测试。

《重构》的笔记-第53页 - 2.1 何谓重构

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。重构之中还可以包含另一个重构，如Extract Class通常包含Move Method和Move Field.重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

《重构》的笔记-第98页 - 4.3 添加更多测试

测试并不是越多越好。其要诀是，测试你最担心出错的部分，这样你就能从测试工作中得到最大利益。
任何测试都不能证明一个程序没有bug。
测试无法捕捉所有bug, 但的确可以捕捉到大多数的bug。

《重构》的笔记-第62页 - 间接层和重构

OO的间接层为代码提供了更强的语意表达能力（函数名可以提供信息 注释和docstring去死去死）、更干净的代码（消除更多重复代码）、更广的共享能力（点我点我点我），可以隔离变化（我也是一名坚定的condition黑 switch黑呢 ），这些都是基于细粒度的方法拆分以及多态特性而产生的。
它唯一的坏处是可能会出现过长的委托链（不能忍）或过多的对象簇（只要拆分得当 对象多可以忍）
如何看待间接层呢 托腮。
晚上回家死鱼眼说他其实不喜欢presenter层 我一定会保守这个秘密不让5long同学知道的 肯定不会。
如何让间接层更有价值？哪些事间接层别做？碰到具体场景大致可以分辨出来吧。

《重构》的笔记-第9页

找出函数内的局部变量和参数任何不会被修改的变量都可以被当成单数传进新的函数。如果只有一个变量被修改，可以把它当做返回值每次修改幅度都很小，所以任何错误都很容易被发现。函数应该放在它使用的数据所属的对象内最好不要在另一个对象的属性基础上运用switch语句。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。
1）把变化的部分，放在变化原本发生的对象
2）封装变化。为了对调用者负责。

《重构》的笔记-第32页

书不错

《重构》的笔记-第61页

计算机科学是这样一门科学：它相信所有问题都是可以通过增加一个间接层来解决。
-- Dennis Debruler

《重构》的笔记-第55页 - 为何重构

为何重构：
1. 改进软件设计。经常性的重构可以帮助代码维持自己该有的形态。
2. 重构使软件更容易被理解。
3. 重构帮助找到Bug.
4. 重构提高编程速度。
事不过三，三则重构。
如果在前进过程中把代码结构理清，我就可以从中理解更多东西。
重构是一个快速流畅的过程，一旦完成重构，新特性的添加就会更快速、更流畅。
我们希望程序：
1， 容易阅读。
2，所有逻辑都只在唯一地点指定。
3，新的改动不会危及更有行为。
4，尽可能简单表达条件逻辑。
间接层的某些价值：
1， 允许逻辑共享。
2，分开解释意图和实现。
3，隔离变化。
4，封闭条件逻辑。