代码重构可修改.pptVIP

任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员 – Martin Fowler 提高代码质量，更易被理解 容易理解的代码可以很容易的维护和做进一步的开发。即使对写这些代码的程序员本身，容易理解代码也可以帮助容易地做修改。程序代码也是文档。而代码首先是写给人看的，让后才是给计算机看的。 Refactoring帮助尽早的发现错(Bugs) Refactoring是一个code review和反馈的过程。在另一个时段重新审视自己或别人代码，可以更容易的发现问题和加深对代码的理解。 Refactoring是一个良好的软件开发习惯。 Refactoring可以提高开发速度 Refactoring对设计和代码的改进，都可以有效的提高开发速度。好的设计和代码质量实体提高开发速度的关键。在一个有缺陷的设计和混乱代码基础上的开发，即使表面上进度较快，但本质是试延后对设计缺陷的发现和对错误的修改，也就是延后了开发风险，最终要在开发的后期付出更多的时间和代价。 项目的维护成本远高于开发成本. 何时重构? 三次法则 第三次做类似的事情是，就需要重构 添加新功能时一并重构 重构是添加新功能最快捷的途径，一旦完成重构，新特性的添加就会更快速、更流畅。 修补错误时一并重构 重构能加深对代码的理解，是代码更加清晰，能帮助我们找出错误bug，重构能帮助写出更健壮的代码。 何时不该重构? 代码太混乱，设计完全错误。与其重构，不如重写。 如果项目已近最后期限,应该避免重构. 如果最后没有足够的时间重构,通常表示早该进行重构。 两顶帽子 [重构]与[添加新功能] 添加新功能时，你不应该修改既有代码，只管添加新功能。 重构时你就不能再添加功能，只管改进程序结构。此外你不应该添加任何测试（除非发现有先前遗漏的东西） 两顶“帽子”可同时进行，一会重构，一会添加新功能。 重构与设计 重构可以带来更简单的设计，同时又不失灵活性,降低了设计过程的难度，减轻了设计的压力。通常情况下我们的设计不是能贯穿我们软件开发的全过程的，在这个过程中，我们的需求变更的可能性非常大，当需求变了，设计也得变，但是我们已有的实现怎么办？全部废除?显然不能！这时候就要依靠重构来解决这种矛盾。 重构与性能 关于重构，有一个常被提出的问题：它对程序的性能将造成怎样的影响？为了让软件易于理解，你常会作出一些使程序运行变慢的修改。这是个重要的问题。但是，换个角度说，虽然重构必然会使软件运行更慢，但它也使软件的性能优化更易进行。 重构与模式 那么真正要实现重构时，我们有哪些具体的方法呢？可以这样说，重构的准则由很多条。但它不是最终的标准，因为你要是完全按照它的标准来执行，那你也就等于不会重构，重构是一种武器，而真正运用武器的高手是没有武器胜有武器。只有根据实际的需要，凭借一定的思想，才能实现符合实际的重构，我们不能被一些固定的模式套牢了，这样你的程序会很僵化。究竟如何把握这个度，需要大家去总结。 重构与思想 要想实现一个好的重构，不是重构本身，而是我们在写代码的时候，思想当中时刻有它的位置存在！非常重要！如果你本身就没想着要去重构，那么就是有再好的模式供你调用又怎么样？就是有了好的模式，你不能根据实际的需要去融会贯通，那你做出来的重构有意义么？ 重构的起源 Ward Cunningham和Kent Beck，Smalltalk里有影响力的专家 Kent Beck，极限编程的领导者 Ralph Johnson，伊利诺伊大学教授，“Gang of Four”之一 Bill Opdyke，Ralph的博士生 Martin Fowler 重构：改善现有代码的设计 重复的代码（Duplicated Code) 过长的函数(Long Method) 过大的类(Large Class) 过长的参数列(Long Parameter List) 发散式变化(Divergent Change) 霰弹式修改(Shotgun Surgery) 依恋情结(Feature Envy) 数据泥团(Data Clumps) 基本类型偏执(Primitive Obsession) Switch语句(Swtich Statements) 平行继承体系(Parallel Inheritance Hierarchies) 冗赘类(Lazy Class) 如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们和而为一，程序会变得更好。 在同一个类中出现重复代码。这时可以采用Extract Method?（提炼函数）提炼出重复的代码，然后让这2个地点都调用被提炼出来的那段代码。 在两个互为兄弟的子类中出现重复代码。只需对2个类都是用Extract Method?（提炼函数），然后