《重构》章节试读

《重构》的笔记-第382页 - 13 重构，复用和现实

通过重新组织软件结构，重构使得设计思路更详尽明确。
重构被用于开发框架、抽取可复用组件、使软件架构更清晰、使新功能的增加更容易。

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

性能提升的一些关键点。
以分解的形式来做性能提升，关键是找出性能热点。然后跟重构一样，小幅度进行修改，每一步都要编译、测试、再次量测，如果没提高性能，就应该撤销此次修改。
重构必然会使软件运行变慢，但它是使优化阶段中软件性能调整更容易。最终还是有赚头。
一直以来自己的毛病是重构的时候把性能优化带进去，弄得每次重构视乎是个深渊，花费很多时间。应该调整下，重构的时候就暂时先抛开性能设想，因为通常所注意的性能影响，十有八九都是影响极小甚至错误的。而只要重构得好，真正遇到性能难题的时候，再去性能优化也变得相当容易。
反之，如果要做性能优化的时候，遇到的是一段十分臃肿且难理解的代码，性能优化也不会简单甚至陷入困局，最终还是要先重构才行方便理解和量测。
简而言之，应当区分好重构和性能提升两个动作，重构往往是性能提升的基本。

《重构》的笔记-3 代码的坏味道 - 3 代码的坏味道

1. 重复代码 （Duplicated Code）
2. 过长函数 （Long Method）
3. 过大的类 （Large Class）
4. 过长参数 （Long Parameter List）
5. 发散式变化 （Divergent Change）
6. 散弹式修改 （Shotgun Surgery）
Divergent Change 是指“一个类受多种变化的影响”，Shortgun Surgery则是指“一种变化引发多个类相应修改”。这两种情况下你都会希望整理代码，使“外界变化”与“需要修改的类”趋于一一对应。
7. 依恋情节 （Feature Envy）
8. 数据泥团 （Data Clumps）
9. 基本类型偏执 （Primitive Obsession）
10. Switch 惊悚现身 （Switch Statements）
11. 平行继承体系 （Parallel Inheritance Hierarchies）
12. 冗赘类 （Lazy Class）
13. 夸夸其谈未来性 （Speculative Generality）
14. 令人迷惑的暂时字段 （Temporary Filed）
15. 过度耦合的消息链 （Message Chains）
16. 中间人 （Middle Man）
17. 狎昵关系 （Inappropriate Intimacy）
18. 异曲同工的类 （Alternative Classes with Different Interfaces）
19. 不完美的库类 （Incomplete Library Class）
20. 纯稚的数据类 （Data Class）
21. 被拒绝的遗赠 （Refused Bequest）
22. 过多的注释 （Comments）

《重构》的笔记-第68页

当下只管建造可运行的最简化系统，至于灵活而复杂的设计，唔，多数时候你都不会需要它。

《重构》的笔记-第90页 - 建立测试体系

说服别人跟你一样编写自我测试类并不容易。编写测试程序，意味着要写很多额外的代码。除非你确实体验到这种方法对编程速度的提升，否则自我测试就显不出它的意义。很多人根本没学过如何编写测试程序，甚至根本没考虑过测试，这对于编写自我测试代码很不利。如果需要手动运行测试，那更是令人烦闷欲呕；但如果可以自动运行，编写测试代码就真很有趣。
工作中一直苦于为啥那么多人不会写测试代码，甚至更苦于说服别人，原来并不是我一个人觉得说服别人写测试代码和写好测试代码是一件困难的事情。

《重构》的笔记-第1页

我只是想知道，笔记出现在哪里？

《重构》的笔记-第107页

许多重构手法...都涉及向系统引入设计模式。
正如GoF的经典著作所说：“设计模式...为重构行为提供了目标。”
模式和重构之间有着一种与生俱来的关系。模式是你希望到达的目标，重构则是到达之路。

《重构》的笔记-第62页 - Indirection and Refactoring

Increase qualitiy by put in indirection
通过引入更多间接的方式提高软件质量
1. To enable share of logic
重用逻辑：被多处调用的子函数或者父类中的函数
2. To explain intention and implementation separately
通过拆分的方法名和类名来阐述方法和类的意图
3.To isolate change
通过子类来隔离变化
4.To encode conditional logic
通过多态来代替条件逻辑
注意：如果间接不能带来好处，则需要通过重构去掉间接，避免预先设计。

《重构》的笔记-第7页

每当我要进行重构的时候，第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。

《重构》的笔记-2.2 为何重构 - 2.2 为何重构

1. 重构改进软件设计
2. 重构使软件更容易理解
3. 重构帮助找到bug
4. 重构提高编程速度

《重构》的笔记-第138页 - 重新组织你的函数

我的重构手法中，很大一部分是对函数进行整理。
几乎所有时刻问题都源于Long Method(过长函数)
#Extract Method的动机喜欢简短而命名良好的函数几个原因
1.颗粒度小，函数彼此复用的机会大
2.使高层函数读起来像一系列注释
3.函数覆写容易（override）

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

重构：在不改变代码外在行为的情况下改善代码的结构，使代码更容易阅读，更容易修改或者添加新功能。
例子中用到的重构方法：
1.将长函数中独立的业务逻辑提取出来，拆分为短函数
2.将函数移动到更合适的类中
3.修改函数名和变量名，使名称符合描述程序行为
4.使用函数调用代替临时变量，临时变量的问题是会导致较长的函数代码。可以将临时变量涉及到的代码抽取为一个函数。
5.用多态替换条件分支
重构目的：
1.代码更易于理解，阅读
2.使代码符合OCP，易于修改

《重构》的笔记-第1页

重构，代码坏味都是本书的重点，如果想知道自己的代码写的有多烂，模式概念理解的是否到位，可以读这本书，能够帮助你一跃成为项目重构的主导者，但是千万别把自己玩进去，哈哈！

《重构》的笔记-第315页

「异常」只应该被用于异常的、罕见的行为，也就是那些「产生意料外的错误」的行为，而不应该成为「条件检查」的替代品。

《重构》的笔记-第206页

Encapsulate Field（封装值域），这点太赞成了！以前不觉得，认为public好用，方便。但实际给编码调试差错带来太多问题。尤其是数据可能在毫无察觉的情况下被修改了，就好比＂人＂这个对象，有＂存款＂这个值域，如果设置成public，＂存款＂被别人修改了都不知道！
从这一点来看，MFC真是害人不浅啊！

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

#重复代码臭味行列首当其冲的就是duplicated code(重复代码)......设法将它们合而为一，程序将变得更好
#过长的函数拥有短函数的对象会活得比较好，比较长。
让短函数真正容易理解的关键在于一个好名字，读者可以通过名字了解其作用。
当我们感觉应该给一个函数加注释的时候，我们就应该把这部分提炼成独立函数，并以用途命名。

《重构》的笔记-第12页

规则1.重构技术以微小的步伐修改步伐，如果你犯下错误，便可以很轻松的发现它

《重构》的笔记-第237页

较之于过程化程序而言，面向对象程序的条件式通常比较少，这是因为很多条件行为都被多态机制处理掉了。

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

Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering)。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而「实用」是软件压倒一切的要素。
TIP：如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
TIP：重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（self-checking）能力。
TIP：重构技术系以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
Smalltalk 也的确拥有这样的工具——Refactoring Browser。运用这个工具，重构过程非常轻松，我只需标示出需要重构的代码，在选单中点选Extract Method，输入新的函数名称，一切就自动搞定。而且工具决不会像我那样犯下愚蠢可笑的错误。

《重构》的笔记-第293页

稳定的接口确实很好，但是被冻结在一个不良接口上，也是有问题的。

《重构》的笔记-第358页

看完前11章，看到好多方法！都非常适用。其实大部分在工作中都用过，只是没有像作者这样归纳总结形成方法论。
不过，文中很多例子太简单，不具备说服力。＂作法＂的讲述也太形式，＂范式＂也枯燥无味，所以我基本都只看每个方法的介绍与＂动机＂部分。

《重构》的笔记-4 构筑测试系统 - 4 构筑测试系统

测试的要诀是：测试你最担心出错的部分。

《重构》的笔记-第58页

何时重构：
1.添加功能时一并重构
2.修补错误时一并重构
3.复审代码时一并重构

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

“把一个简单的解决方案重构成这个灵活的方案有多大难度？”如果答案是“相当容易”，那么你就只需实现目前的简单方案就行了。
简单设计，并且容易修改成灵活方案时，简单设计优于灵活方案。因为灵活，意味着带来更多的复杂性，虽然可以更好适应变化，但这些好处会不知道什么时候才用得上。保持简单就行了。
至于那些灵活和复杂的设计，多数时候你都不会需要它。
少数情况是指，有些客户的需求变动比较多，使程序不得不做成灵活易改来适应变化，随之而来也会变得越来越复杂（因为应当先保证程序正常为原则）。但项目期限紧迫，应当还是交付需求优先，所以这时还是需要灵活和复杂的设计，只是在交付期限允许的情况下可以适当的重构，令程序逐步变得不那么复杂。

《重构》的笔记-第12页

细看也没用上，因为自己一段时间后不喜欢改自己代码

《重构》的笔记-第1页

向别人讲解时，不要流于俗套。历史、原理...，这样会勾起每个人的瞌睡虫。让大家思绪游荡，眼神迷离。谈原理，很容易流于泛泛，又很难说明如何实际使用。给出一个实例，却可以帮助我们把事情认识清楚。

《重构》的笔记-第55页

代码数量减少并不会使系统运行更快，因为这对程序的运行轨迹几乎没有任何明显影响。然而代码数量减少将使未来可能的程序修改动作容易得多。

《重构》的笔记-第15页

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。
使用更加表意的变量名、函数名、类名等等，都是增加代码清晰度，提高代码表达力的最简单、直接的手段。代码是写给人看的，永远不要怀疑这样小的修改是否值得或是否有必要。
thisAmout -> result
each -> aRental

《重构》的笔记-第7页

每当我要进行重构的时候，第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。这些测试是必要的，因为尽管遵循重构准则可以使我避免绝大多数的臭虫引入机会，但我毕竟是人，毕竟有可能犯错。所以我需要可靠的测试。

《重构》的笔记-第52页

重构的节奏：测试、小修改、测试、小修改、测试、小修改...

《重构》的笔记-

mark

《重构》的笔记-第52页

测试对重构至关重要，是保证程序不因重构引入bug的前提。
基于pojo的编程比较清晰，但是需要大量的处理器等类来加工/处理，都使用这种方法会不会导致程序更加面向过程？缺少面向对象的感觉。
好像有人认为大量以er结尾的类，会导致软件去对象化。大致是这个意思，具体怎么说的不记得了。

《重构》的笔记-第2页

本质上说，重构就是在代码写好之后改进它的设计。

《重构》的笔记-第62页 - 重构的难题

重构也有他自己的难题，就如对象技术(object tech.)并非十全十美一样。重构虽然可以给我们带来随手可得的变化，但是不代表它就没有其局限性和难以解决的问题。书中主要指出以下几点，更多问题待累积足够的经验后发掘。
一、数据库
在非对象数据库中。由于数据库厂商和database schema紧密耦合(coupled)，在修改和迁移数据库的时候，必须进行重新的修改，是一件噩梦的工作。重构唯一能做的就是加入分隔层(hibernate)。但会增加复杂度和牺牲效率。
如果在对象数据库中，也会牺牲时间，而且也因为不知道数据库结构变化而处于混沌状态。

二、修改接口
1、许多重构的手法会修改接口。这样意味着所有调用者都必须知道这一变化才能保证程序能正常运作。解决办法是，在新接口完成的时候保留旧接口，在旧的接口实现上调用新的接口方法，并且在旧方法上标识deprecated注释作说明，这样稍微会有略为复杂。
2、减少发布的接口，能不发布就尽量不发布，避免重命名接口问题。
3、不要忽略异常，因为异常（checked）有可能随着实现类的增加。可以封装自定义异常进行checked异常的封装或者把checked异常转化成unchecked异常，并加以说明。
三、难以实现设计的改动
如果某些核心设计决策错了，是很难以重构手法修改的。例如将“无安全需求”情况下构造起来的系统重构为“安全性良好的系统”。
解决办法是，在选择设计方案的时候，往往会选择最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不到简单的重构方法，就会投入更多的力气。不过这种情况很少出现。

《重构》的笔记-第1页

相同页的笔记会合并吗？

《重构》的笔记-第97页

每当你收到bug报告，请先写一个单元测试来暴露这只bug。

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

忘记一个重要的话题了，虽然意思一直理解着，自己写一遍好了：重构和性能优化，都不会改变组件(功能)的原有行为。然而，他们的出发点不同，性能优化往往使代码较难理解，但为了得到所需要的性能你不得不那么做（例如SQL查询）。

《重构》的笔记-第8页

古老的工程学格言：如果它没坏，就别动它。
如果有需要的话，先重构，再添加新特性。
先保证测试，再开始重构。
重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（self-checking）能力。

《重构》的笔记-第2页

所谓重构(refactoring)是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

《重构》的笔记-第237页

多态还有一种十分有用但鲜为人知的用途：通过引入Null对象去除对于null value的检验。

《重构》的笔记-第91页 - JUnit测试框架

这章比较全面并且深入浅出说明了下JUnit测试框架，是比较适合教那些不会写JUnit的人简单的认识一下也恰好同为使用Java的人，示例变得更加容易理解。覆盖的三个名词test-suite、test-case和test-fixture

《重构》的笔记-第464页

重构就是修改软件，在保持软件行为的基础上改变软件结构。
保持软件行为意味着软件大部分功能已经可用，这是用到回归测试的地方。
作者定义了一种叫做“坏味道”的启发式，来查找软件中需要修改的地方。这种“坏味道”指的是一般可理解性差，修改成本高的代码。这些代码有的来自于匆忙的程序实现，有的来自于匆忙的软件设计。
1、 小的是美好的。如果一个整体包含的个体比较少，那么其个体之间的关系就会比较少，该整体从而容易改变。必要的时候要把整体打散、重组。
2、 抓住最重要的。如果组织个体具有两个以上的方式，选择最重要的一个形成整体结构。
3、 选出最典型的。如果个体具有同样的行为，用一个角色（接口）去代表它们。如果同样的行为序列出现多次，引入一个设计模式。
4、 识别最稳定的。区分变化与稳定的部分，为容易变化的部分提供间接性。
5、 留下最熟悉的。用一个容易理解的名字把不容易理解的部分包装起来。用容易理解的模型解释不容易理解的技术。
http://refactoring.com/catalog/index.html

《重构》的笔记-第1页

跟代码大全有很多相似的内容

《重构》的笔记-第13页

重构技术系以微小的步伐修改程序。如果你犯下错误，很容易便可发现他。
要有测试，测试要self-checking，频繁运行。

《重构》的笔记-2.3 何时重构 - 2.3 何时重构

1. 三次法则
2. 添加功能时重构
3. 修补错误时重构
4. 复审代码时重构

《重构》的笔记-第69页

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

《重构》的笔记-第1页

刚刚看几页，果然名不虚传！顶，都有马上回去重构的冲动了！

《重构》的笔记-第6页

代码好坏的评判其实大部分源于美学，编译器才不管字母的排列顺序，CPU更不在乎二进制是什么。只要最终能够跑起来，满足客户需要。貌似，真的无关乎写的美丑。
是吗？真的是这样吗？
当需求变更时，你知道这肯定会发生的，我们就需要修改系统，谁去修改呢？不是编译器，也不是CPU。是的，你明白的，是人！人要去阅读代码，并作出对应的修改。如果代码难于阅读，也就很难修改，很难做的事情就容易犯错，从而引入bug的可能就更大。
什么是这一切的开始呢？嗯，就是写的丑陋的代码！

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

重写和重构老是有人搞混淆，当然其实觉得这并不是一个很严谨的话题，就算分不清重写和重构，从结果上来看，两者都会令代码正常运行。只是如果你除了令代码正常运行外，还使代码变得更容易修改和阅读了，这时你就是重构了。至于真的要说的话，关键就在修改前的代码是否能正常运行，如果不行，首当其冲的就是要重写。因为重构之前，代码必须起码能够大部分情况下正常运作。

《重构》的笔记-第54页

但是两者出发点不同：性能优化往往使代码较难理解，但为了得到所需的性能你不得不那么做。