重构初体验讲解内容名言重构介绍重构原则2、提高代码质量，更易被理解容易理解的代码可以很容易的维护和做进一步的开发。即使对写这些代码的程序员本身，容易理解代码也可以帮助容易地做修改。程序代码也是文档。而代码首先是写给人看的，让后才是给计算机看的。3、重构帮助尽早的发现错重构是一个codereview和反馈的过程。在另一个时段重新审视自己或别人代码，可以更容易的发现问题和加深对代码的理解。重构是一个良好的软件开发习惯。4、重构可以提高开发速度重构对设计和代码的改进，都可以有效的提高开发速度。好的设计和代码质量实体提高开发速度的关键。在一个有缺陷的设计和混乱代码基础上的开发，即使表面上进度较快，但本质是试延后对设计缺陷的发现和对错误的修改，也就是延后了开发风险，最终要在开发的后期付出更多的时间和代价。项目的维护成本远高于开发成本.何时重构1、添加新功能时一并重构为了增加一个新的功能，程序员需要首先读懂现有的代码。2、修补错误时一并重构为了修复一个Bug,程序员需要读懂现有的代码。3、CodeReview时一并重构何时不该重构1、代码太混乱，设计完全错误。与其Refactor，不如重写。2、明天是DeadLine永远不要做Last-Minute-Change。推迟重构，但不可以忽略，即使进入Production的代码都正确的运行。3、重构的工作量显著的影响最后期限一个Task的计划是３天，如果为了重构，需要更多的时间（２天或更多）。推迟重构,同步可以忽略。可以把这个重构作为一个新的Task，或者安排在重构的Iteration中完成。重构有关特性重构与模式那么真正要实现重构时，我们有哪些具体的方法呢？可以这样说，重构的准则由很多条，见《重构》这本书。但它不是最终的标准，因为你要是完全按照它的标准来执行，那你也就等于不会重构，重构是一种武器，而真正运用武器的高手是没有武器胜有武器。只有根据实际的需要，凭借一定的思想，才能实现符合实际的重构，我们不能被一些固定的模式套牢了，这样你的程序会很僵化。究竟如何把握这个度，需要大家去总结。代码坏味道重复的代码如果你在一个以上地点看到相同的程序结构，那么可以肯定：设法将他们合二为一，程序会变得更好。过长函数程序员都认识到：程序越长越难理解。每当感觉需要以注释来说明点什么的时候，我们就把需要的东西写进一个独立函数中，并以其用途为名。将一个长方法分解为几个小方法，不但利于理解，而且能发现通常有很多方式能够使它们共享逻辑(方法重用)。过大的类如果想利用单个类做太多事情，其内往往就会出现太多实例变量。一个过大的类往往存在维护难、理解难的等问题，那就应该把它分为几个小类。过长参数列太长的参数列难以理解，太多参数会造成前后不一致，不易使用，而且一旦你需要更多的数据，就不得不修改它。可以通过传递对象类解决。发散式变化如果某个类经常因为不同的原因在不同的方向上发生变化，此时发散就出现了。需要找到某特定原因而造成的所有变化，然后把他们提取到一另一个类中。霰弹式修改如果遇到某种变化，你都必须在许多不同CLASS内作出许多小修改以相应之依恋情节函数对某一个类的兴趣高过了对自己所处类的兴趣。我们会看到某个函数为了计算某一个值，从另一个对象那里调用到很多取值函数。对应原则：判断那个类拥有最多被次函数调用的数据，然后就把这个函数和那些数据摆在一起。数据泥团常常在很多地方看到相同的三四项数据：两个类中有相同的字段，很多函数签名中相同的参数，这些总是绑在一起出现的数据应该有属于他们自己的对象。switch惊悚现身面向对象程序的一个最明显特征就是：少用switch(或case)语句。switch的问题在于重复。如果添加一个case就要找到所有的switch去修改。冗赘的类如果一个类的所得不值其身价，它就应该消失。过度耦合的消息链如果看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后在向后者请求另一个对象...这就是消息链。这样的方式客户端代码将查找过程中的导航结构紧密耦合，一旦对象之间关系发生任何变化，客户端就的做出相应修改。中间人当某个CLASS接口有一半的函数都委托给其他CLASS时，就存在过度应用了。这时应该直接和实际对象打交道。不恰当的亲密关系过分亲密的类必须拆散。帮它们划清界面，从而减少亲密行为异曲同工的类如果两个函数做同一件事情去，却有着不同的签名，需应用renamemethod根据他们的用途重新命名重构技巧重新组织你的函数提炼函数有一段代码可以被组织在一起并独立出来，将这段代码放进一个独立函数中，并让函数名称解释该函数的用途。在对