重构的详解.docVIP

重构-改善既有代码的设计 读书笔记 重构-改善既有代码的设计 重构，第一个案例 重构原则 何为重构 1. 名词：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本 2. 动词：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构 和性能优化形成对比 都不改变组件的行为，只改变内部结构 目的不同，重构的目的是使软件更容易被理解 两顶帽子 来回换，但是尽量不同时做 添加新功能 重构 为何重构 重构改进软件设计 防止程序的设计逐渐腐败变质 消除重复，让所有的事物和行为在代码中只表述一次，这正是软件设计的根本 重构是软件更容易理解 研究理解别人的代码的时候，也可以尝试重构，Ralph Johnson把这种“早期重构”描述为“擦掉窗户上的污垢，使你看得更远” 重构帮助找到bug 重构能帮助写出更健壮的代码 最终，重构提高编程速度 何时重构 随时随地，不需要专门重构，重构是因为你想做别的什么事，而重构可以帮助你把那些事情做好 三次法则 第三次做类似的事情，就应该重构 添加功能时重构 修补错误是重构 复审代码时重构 重构的难题 数据库 修改接口 难以通过重构的手法完成的改动 何时不该重构 既有代码太混乱，重构它还不如重新写一个来得简单 重构之前，代码必须保证能够在大部分情况下正常运作，否则就重写 可以先重构为封装良好的小型组件，然后就可以逐一对组件作出重构或者重建 项目已经接近最后期限，避免重构 如果最后你没有足够的时间，通常就表示你其实早就该进行重构 重构与设计 有了设计，我可以更快的思考，但是其中充满小漏洞 极限编程的支持者极力支持使用重构取代预先设计，CRC卡 重构与性能 首先写出可调的软件，然后调整它以求获得足够的速度 在性能优化阶段，首先要度量 重构起源何处 Ward Cunningham Kent Beck Ralph Johnson Bill Opdyke John Brant Don Roberts 代码的坏味道 重复代码（Duplicated Code） 同一个类两个函数 互为兄弟的子类 只是类似，并非完全相同 两个不相干的类出现重复 Extract Method, Pull Up Method, Form Template Method, Template Method, Substitute Algorithm, Extract Class 过长函数（Long method） 间接层所能带来的全部利益--解释能力，共享能力，选择能力--都是由小型函数支持的 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名 条件表达式和循环常常也是提炼的信号 Extract Method, Replace Temp with Query, Introduce Parameter Object, Preserve Whole Object, Replace Method with Method Object, Decompose Conditional 过大的类（Large Class） 先确定客户端如何使用它们，然后运用Extract Interface为每一种使用方式提炼出一个接口。这或许可以帮助你看清楚如何分解这个类 Extract Class, Extract Subclass, Extract Interface, Duplicate Observed Data 过长参数列表（Long Parameter List） Replace Parameter with Method, Preserve Whole Object, Introduce Parameter Object 发散式变化（Divergent Change） 针对某一处外界变化的所有相应修改，都应该发生在单一类中,而这个新类内的所有内容都应该反应此变化 Extract Class 霰弹式修改（Shotgun Surgery） 和发散式修改相反 把所有的需要修改的代码放进同一个类 整理代码，使外界变化和需要修改的类趋于一一对应 依恋情节（Featrue Envy） 函数对某个类的兴趣高于对自己所处类的兴趣 Strategy,Visitor,SelfDelegation破坏了这个规则，使用这些模式是为了对抗坏味道Divergent Change。最根本的原则是：将总是一起变化的东西放到一块 标记: 黄色 Extract Method, Move Method 数据泥团（Data Clumps） 两个类中的相同的字段，许多函数签名中的相同的参数 删掉众多数据中的一项，这么做，其他的数据有没有因而失去意义，如果它们不再有意义，这就是个明确的信号：你应该为它们