如何进行重构.pptVIP

重构－回归设计 ZONDY CYBER GROUP CO.,LTD * 2008-08-04 彭裕辉 为何重构??? 后期代码增加，功能修改会破坏原来的设计结构，导致系统难于维护，前 期的设计失去意义 可以弥补前期设计缺陷，增强系统的稳定性，提高系统的易维护性 让系统维护变得更有乐趣，让自己的设计经验得意提高 重构(回归设计)：在不改变代码外在行为的前提下，对代码作出修改，以改进 程序的内部结构. 何时，何地重构？任何时候，任何地点都可以重构，重构是 是渐进的过程，不是一次搞定就OK的，只有渐进重构，你将会受益很多！ BAD SMELLS 坏味道 程序代码中一些不合理的特征，这些不合理的特征有的导致程序是难于维护的，有 的是难于理解的，有的会破坏对象的封装性，有的会破坏系统的独立性，有的会增 强对象的偶合度，这些不合理的特征就是重构的对象。 视这些Bad smells 而不见，作为一个程序员来说是不尽职的！所以我们要重 构这些代码，或者重构类体系，甚至是整个系统！ 十大臭名招剧的BAD SMELLS 臭名排行榜 1.Duplicated Code 重复代码 维护困难：一旦从这些重复的代码中找出一个臭虫，那么就意味着这个臭虫 会在所有的重复代码中出现，你将不得不修改5、10处甚至是更多处代码！ 修改其中n－1个臭虫其实都是在做无用功！ 合而为一，在所有出现重复代码的地方调用合并后的函数或者对象 减少了代码量、减少了BUG数量，减少了维护成本，增强了模块独立性，增 了程序的灵活性。 2.Long Method 过长函数 函数写的越长出错的几率越大，灵活性越小，可读性越差。当下次你在编程的时候 发现你仅仅需要使用到某一函数中的一部分功能而不是其全部功能时，你将不得不 从这个函数中拷贝出那份代码，重新写一个函数供你使用，如此：Duplicated code 又出现了，噩梦也来了！ 分解他们，将函数内部相对功能独立的部分分解出来作为一个新的函数，给它起一 个好名字，刚好能够解释它的意图的名字。如果这个函数还是太长，再将它分解， 总之，不要让一个函数做太多的事情，让它做它刚刚能做的事情就好！ 寻找注释：当你在编写代码的时候，觉得需要写注释才能让别人看懂下面接下来要 做什么的时候，请你注意：“你即将写的这段代码大概应该被提炼为一个Method啦” 好的代码有好的名字，短的结构，可以不需要注释！短代码：解释能力强、共享能 力强、选择能力强！ 3.Large Class 过大类 一个类如此之大，以至于它有如此之多的方法，它几乎什么都可以做，这样太 好了，那我们就只需要这一个类，就可以完成我们新系统的所有功能了！ 一个类一个系统，My God ！！！ 过大类导致通用性差，耦合度提高，复杂度高，消灭这样的类！ 将这样的类按照功能进行分解，将相关的成员变量提炼到一个新的类，将对这些 数据的操作封装到新的类中。 如果你有一个很大的类， CBig，什么都可以做，可以写字、画画、还可以播放音 乐。假如客户端仅仅只有电源，那么它将不能使用CBig来完成音乐播放，因为可 能CBig还需要其它的诸如：墨水，铅笔等东西来完成初始化，够糟糕的，功能这 么强大的一个CBig对我来说却是不适用的！ 不过拆开CBig为CBruch, CPen, CMp4，呵呵，这样就好了！ 4.Long Parameterlist 过长参数列 太长的参数列，难以理解，会造成前后不一致，不易使用，而且一旦需要更 多的数据，就不得不修改这个接口函数。 有10个参数的函数，估计人见人怕，而且谁知道那一天这个函数的参数个数 会涨到11个呢？这样的函数我也不会用，还是找别的可以替代的来用吧！ 这个函数真的需要这么多个参数吗？将不需要的参数剔除，如果真的需要这 么多参数，可以将这些参数封装为一个类，将这个类的对象作为参数，这样 就只用一个参数了，看起来简单了很多，而且扩展性也强了很多！因为如果 将来你发现还需要一个参数M，也许你会惊奇的发现那个类中不是有这个变 量吗！OK，拿来只用就好了！函数参数列不用修改了！ 5.Feature Envy 依恋情结 函数对某个class的兴趣高过对自己所处的host class的兴趣，某一个函数希望做 某一件事情的时候，从另外一个对象那儿调用几乎半打取值函数得到数据进行处 理，圣旨想钻到那个类怀抱中访问没有提供取值设置的私有成员变量！ What can we do? 成全他们！ 对象的数据合与数据相关行为应该是密不可分的，他们就应该像一对钟情的情人 ，请将他们总是放在一起，不要将他们分开！ 脚踏两只或者更多船是不好的！ 6.Switch Statements Switch泛滥 从