重构(zhang).docVIP

重构(Refacting) 什么是重构？代码写好之后，对它进行重新设计，但并不改变原有代 的逻辑（可以包括对方法名，变量名，常量的抽取和优化） 2、 进行重构的时候，我们需要依赖测试，让它告诉我们是否引入了臭虫。好的测试是重构的根本。?3、 重构的节奏：测试、小修改、测试、小修改、……?4、 “两顶帽子”：使用重构技术开发软件时，你把自己的时间分配给两种截然不同的行为：“添加新功能”和“重构”。添加新功能时，你不以你更改修改既有代码， 只管添加新功能。通过测试，你可以衡量自己的工作进度。重构时你就不能再添加功能，只管改进程序结构。此时你不应该添加任何测试（除非发现先前遗漏的任何 东西），只在绝对必要时（用以处理接口变化）才修改测试。?5、 何时重构？三次法则，第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是做了；第三次再做类似的事，你就应该重构。?1） 添加功能时一并重构；2）修补错误时一并重构；3）复审代码时一并重构。?6、 重构的难题：数据库；修改接口；难以通过重构手法完成的设计改动。?7、 何时不该重构？重写而非重构的一个清楚讯号就是：现有代码根本不能正常工作。如果项目已近最后期限，你也应该避免重构。?-------------------------------------------------------------------------------?8、 “臭味条款”—Kent Beck?1） Duplicated Code(重复代码)?2） Long Method（过长函数）?3） Large Class（过大类）?4） Long Parameter List（过长参数列）?5） Divergent Change（发散式变化）——过耦合?6） Shotgun Surgery(散弹式修改)——过度的分散与过耦合相反?7） Feature Envy（依恋情节）——函数对某个class的兴趣高过对自己所处的host class的兴趣。症状：某个函数为了计算某值，从另一个对象那调用机会半打的取值函数。疗法：把这个函数移动到另一个地点。?8） Data Clumps（数据泥团）——症状：总是绑在一起出现的数据，很多地方可以看到相同的三或四笔数据项：两个classes内的相同值域、许多函数签名式中的相同参数。疗法：把这些数据放进属于它们自己的对象中。?9） Primitive Obsession（基本型别偏执）——两种数据：结构型别和基本型别。充分利用“对象”的价值，它模糊了横亘于基本数据和体积较大的classes之间界限。例如以class表示字符串和日期。?10） Switch Statements（switch惊悚现身）——面向对象程序的一个最明显特征就是：少用switch语句。多态的概念可以为此带来优雅的解决办法。?11） Parallel Inheritance Hierarchies(平行继承体系)——每当为某个class增加一个subclass，必须也为另一个class相应增加一个subclass。?12） Lazy Class（冗赘类）——如果一个class的所得不值其身价，他就应该消失。?13） Speculative Generality（夸夸其谈未来性）——以为“总有一天需要做这事”并因而企图以各式各样的挂钩和特殊情况来处理一些非必要的事情。?14） Temporary Field（令人迷惑的暂时值域）——对象内某个instance变量仅为某种特定情势而设。?15） Message Chains（过度耦合的消息链）——用户向一个对象所求另一个对象，然后再向后者所求另一个对象，然后……这就是消息链。?16） Middle Man（中间转手人）——某个class接口有一般的函数都委托给其他class，这样就是过度运用。?17） Inappropriate Intimacy（狎昵关系）——两个类之间过分亲密?18） Alternative Classes with Different Interfaces（异曲同工的类）——两个函数做同样的事情，却有着不同的签名式。?19） Incomplete Library Class（不完美的程序库类）?20） Data Class（纯稚的数据类）——只含有一些值域以及访问值域的方法?21） Refused Bequest（被拒绝的遗赠）——子类应该集成弗雷的函数和数据。但如果他们不想或不需要继承。?22） Comments(过多的注释)?23） 如何学习？1)随时挑一个目标；2)没有把握就停下来：你无法证明自己所做的