坏味道--数据泥团(Data Clumps) 特征 有时,代码的不同部分包含相同的变量组(例如用于连接到数据库的参数).这些绑在一起出现的数据应该拥有自己的对象. 问题原因 通常,数据泥团的出现时因为糟糕的编程结构或"复制-粘贴式编程". 有一个判断是否是数据泥团的好办法:删掉众多数据中的一项.这么做,其他数据有没有因而失去意义?如果它们不再有意义,这就是个明确的信号:你应该为它们产生一个新的对象. 解决方法 首先找出这些数据以字段形式出现的地方,运用 提炼类(Extract Clas

我们的项目中是否充斥着类似以下的代码呢?定义一个专门存放常量的java类(接口),非常多其它类依赖该常量类. public interface IConstant { int ZERO = 0; String EMPTY_STRING = ""; } 使用该常量的代码,大致具有例如以下形式: List<String> list = new ArrayList<String>(IConstant.ZERO); if(IConstant.ZERO == list.s

更多原创测试技术文章同步更新到微信公众号 :三国测,敬请扫码关注个人的微信号,感谢! 原文链接:http://www.cnblogs.com/zishi/p/6766994.html 众所周知Sonar是一个很强大的静态扫描工具,代码提交之后可以自动触发代码扫描,并给出report,因此给开发项目带来了很多便利. 日前我把本地版本升级到6.2了,项目的度量项也增加了许多.看过去一堆的ABCD,A应该是最好,D最差,但是中间的差别还是需要弄清楚. 为了更好的理解,我详细翻看了官方文档,同时也参考了

更多原创测试技术文章同步更新到微信公众号 :三国测,敬请扫码关注个人的微信号,感谢! 原文链接:http://www.cnblogs.com/zishi/p/6766994.html 众所周知Sonar是一个很强大的静态扫描工具,代码提交之后可以自动触发代码扫描,并给出report,因此给开发项目带来了很多便利. 日前我把本地版本升级到6.2了,项目的度量项也增加了许多.看过去一堆的ABCD,A应该是最好,D最差,但是中间的差别还是需要弄清楚. 为了更好的理解,我详细翻看了官方文档,同时也参考了

刚开始学习编程时,老师说:讲方法所需要的东西都以参数的形式传入,那是我们好像还没学OO这个东东,要不就弄成全局变量,我擦,全局变量可牛逼了,刚开始学习的时候我们都在用全局变量,可是后来工作了,经理说不要用全局变量,我当时就有些醉了,突然间觉得就不会写代码了,其实我们可以用对象来解决这个问题,这样我们就不会开到过长的参数列表了 private DataTable getSentInfo(string Pno, string Pname, string Psytle, string SentTime

1.重构 1.1 为什么要重构 1.1.1 改进程序设计 程序员为了快速完成任务,在没有完全理解整体架构之前就开始写代码, 导致程序逐渐失去自己的结构.重构则帮助重新组织代码,重新清晰的体现 程序结构和进一步改进设计. 1.1.2 提高程序可读性 容易理解的代码很容易维护和增加新功能.代码首先是写给人看的, 然后才是计算机看的.   重构是一个Code Review 和反馈的过程.在另一个时段重新审视代码, 会容易发现问题和加深对代码的理解. 1.2 利用重构技术开发软件时会把时间分配给两种行为

1.Duplicated Code(重复的代码) 臭味行列中首当其冲的就是Duplicated Code.如果你在一个以上的地点看到相同的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好. 最单纯的Duplicated Code就是［同一个class内的两个方法含有相同表达式(expression)］.这时候你需要做的就是采用Extract Method提炼出重复的代码,然后让这两个地点都调用被提炼出来的那一段代码. 另一种常见情况就是[两个互为兄弟(sibling)的subclass

"如果尿布臭了,就换掉它." --Beck奶奶,论保持小孩清洁的哲学 代码的坏味道这一章集中论述该何时重构.具体的重构方法在后面的章节. "没有任何度量规矩比得上见识广博者的直觉.你必须培养自己的判断力,学会判断一个类中有多少实例变量才算太大,一个函数内有多少代码才不算太长." ​ --Martin Flower 3.1 改名 深思熟虑给函数,模块,变量和类命名,使其清晰的表明自己的功能和用法. 重构手法之一:改名(改变函数声明,变量改名,字段改名) 3.2 消除重

坏味道--重复代码(Duplicate Code) 重复代码堪称为代码坏味道之首.消除重复代码总是有利无害的. 特征 两个代码片段看上去几乎一样. 问题原因 重复代码通常发生在多个程序员同时在同一程序的不同部分上工作时.由于他们正在处理不同的任务,他们可能不知道他们的同事已经写了类似的代码. 还有一种更隐晦的重复,特定部分的代码看上去不同但实际在做同一件事.这种重复代码往往难以找到和消除. 有时重复是有目的性的.当急于满足deadline,并且现有代码对于要交付的任务是"几乎正确的"时

坏味道--纯稚的数据类(Data Class) 特征 纯稚的数据类(Data Class) 指的是只包含字段和访问它们的getter和setter函数的类.这些仅仅是供其他类使用的数据容器.这些类不包含任何附加功能,并且不能对自己拥有的数据进行独立操作. 问题原因 当一个新创建的类只包含几个公共字段(甚至可能几个getters / setters)是很正常的.但是对象的真正力量在于它们可以包含作用于数据的行为类型或操作. 解决方法 如果一个类有公共字段,你应该运用 封装字段(Encapsulat

sourcemaking 如果一段代码是不稳定或者有一些潜在问题的,那么代码往往会包含一些明显的痕迹.正如食物要腐坏之前,经常会发出一些异味一样, 我们管这些痕迹叫做 "代码异味".今天让我们一起来熟悉开发中经常出现的22种坏味道情形和解决方法. Duplicated Code 重复代码 不良影响 解决方法 重复代码,难维护 提取公共函数 Long Method 函数长 不良影响 解决方法 函数长, 难理解 拆分成若干函数 Large Class 类大 不良影响 解决方法 类大, 难理

坏味道--狎昵关系(Inappropriate Intimacy) 特征 一个类大量使用另一个类的内部字段和方法. 问题原因 类和类之间应该尽量少的感知彼此(减少耦合).这样的类更容易维护和复用. 解决方法 最简单的解决方法是运用 搬移函数(Move Method) 和 搬移字段(Move Field) 来让类之间斩断羁绊. 你也可以看看是否能运用 将双向关联改为单向关联(Change Bidirectional Association to Unidirectional) 让其中一个类对另一个

坏味道--依恋情结(Feature Envy) 特征 一个函数访问其它对象的数据比访问自己的数据更多. 问题原因 这种气味可能发生在字段移动到数据类之后.如果是这种情况,你可能想将数据类的操作移动到这个类中. 解决方法 As a basic rule, if things change at the same time, you should keep them in the same place. Usually data and functions that use this data ar

坏味道--被拒绝的馈赠(Refused Bequest) 特征 子类仅仅使用父类中的部分方法和属性.其他来自父类的馈赠成为了累赘. 问题原因 有些人仅仅是想重用超类中的部分代码而创建了子类.但实际上超类和子类完全不同. 解决方法 如果继承没有意义并且子类和父类之间确实没有共同点,可以运用 以委托取代继承(Replace Inheritance with Delegation) 消除继承. 如果继承是适当的,则去除子类中不需要的字段和方法.运用 提炼超类(Extract Superclass) 将

坏味道--临时字段(Temporary Field) 特征 临时字段的值只在特定环境下有意义,离开这个环境,它们就什么也不是了. 问题原因 有时你会看到这样的对象:其内某个实例变量仅为某种特定情况而设.这样的代码让人不易理解,因为你通常认为对象在所有时候都需要它的所有变量.在变量未被使用的情况下猜测当初设置目的,会让你发疯. 通常,临时字段是在某一算法需要大量输入时而创建.因此,为了避免函数有过多参数,程序员决定在类中创建这些数据的临时字段.这些临时字段仅仅在算法中使用,其他时候却毫无用处. 这

坏味道--过大的类(Large Class) 特征 一个类含有过多字段.函数.代码行. 问题原因 类通常一开始很小,但是随着程序的增长而逐渐膨胀. 类似于过长函数,程序员通常觉得在一个现存类中添加新特性比创建一个新的类要容易. 解决方法 设计模式中有一条重要原则:职责单一原则.一个类应该只赋予它一个职责.如果它所承担的职责太多,就该考虑为它减减负. 如果过大类中的部分行为可以提炼到一个独立的组件中,可以使用 提炼类(Extract Class). 如果过大类中的部分行为可以用不同方式实现或使用于

坏味道--基本类型偏执(Primitive Obsession) 特征 使用基本类型而不是小对象来实现简单任务(例如货币.范围.电话号码字符串等). 使用常量编码信息(例如一个用于引用管理员权限的常量USER_ADMIN_ROLE = 1 ). 使用字符串常量作为字段名在数组中使用. 问题原因 类似其他大部分坏味道,基本类型偏执诞生于类初建的时候.一开始,可能只是不多的字段,随着表示的特性越来越多,基本数据类型字段也越来越多. 基本类型常常被用于表示模型的类型.你有一组数字或字符串用来表示某个实

坏味道--过长参数列(Long Parameter List) 特征 一个函数有超过3.4个入参. 问题原因 过长参数列可能是将多个算法并到一个函数中时发生的.函数中的入参可以用来控制最终选用哪个算法去执行. 过长参数列也可能是解耦类之间依赖关系时的副产品.例如,用于创建函数中所需的特定对象的代码已从函数移动到调用函数的代码处,但创建的对象是作为参数传递到函数中.因此,原始类不再知道对象之间的关系,并且依赖性也已经减少.但是如果创建的这些对象,每一个都将需要它自己的参数,这意味着过长参数列. 太

1  对用户输入做过多的约定和假设 配置文件App.config中有一个设定报表路径的配置节: <add key="ReportPath" value="C:\Users\Administrator"/> 在程序中有一个销售报表文件SalesReport.rpt,用代码调用这个报表,可能会写成: string salesReport=ReportPath + "SalesReport.rpt"; 因为路径末尾没有加反斜线,会抛出找不到

膜拜下 Martin Fowler 大神 , 开始学习 圣经 重构-改善既有代码设计 . 代码的坏味道就意味着需要重构, 对代码的坏味道了然于心是重构的比要前提; . 作者 : 万境绝尘 转载请注明出处 : http://blog.csdn.net/shulianghan/article/details/20009689 . 1. 重复代码 (Duplicated Code) 用到的重构方法简介 : Extract Method(提炼函数), Pull Up Method(函数上移), From