读【重构】读书笔记之一 代码的坏味道

一、重复的代码: 包含完全重复、部分重复、以及程序不同结果相同

1)一个类的两个函数有相同的表达式  ---提取方法

2)两个互为兄弟的子类含有相同表达式----提取方法,放在父类

3)两个毫不相干的类中的重复----引入第三方类

4)如果代码只是类似,并非完全相同----分割出相同部分构成独立方法

5)有些函数以不同算法做相同的事----选择其中清晰的一个

二、过长的函数

1)积极分解函数,每当我们需要以注释来说明点什么的时候,就可以写进独立的函数了。并以其用途命名(而非实现手法),这样就不需要总是跳转来阅读程序,通过名字知道函数做了什么。我们可以对一组甚至短短一行代码做这件事,哪怕替换后的函数调用动作比函数自身还长。

2)条件表达式

3)循环

注意,尽量的干掉参数和临时变量,增加可读性。

三、过大的类

四、过长参数列

五、发散式修改:一个类受多种变化原因的影响而引发修改

六、霰弹式修改:一种变化引发多个类做修改

七、依恋情结

八、数据泥团

把一堆参数提炼为一个对象来传递是值得的

九、基本类型偏执

十、switch

十一、平行继承体系

十二、冗赘类

十三、夸夸其谈未来性

十四、令人迷惑的暂时字段

十五、过度耦合的消息链

十六、过度委托

十七、狎昵关系

十八、异曲同工的类

十九、不完美的库类

二十、純稚的数据类

二十一、被拒绝的遗赠

二十二、过多的注释

注释可以卸下自己为什么做某某事,可以标记并无十足把握的区域等

时间: 2024-11-18 22:23:50

读【重构】读书笔记之一 代码的坏味道的相关文章

关于重构(四)--代码的坏味道

代码的坏味道主要有: Duplicated Code---(重复的代码):如果你在两个以上的地点看到相同的程序结构,那可以:设法将它们合二为一,程序会变得更好. Long Method ------(过长函数): 1 private void bindSaleInfo(string swhere) 2 { 3 ArrayList proList = getProductInfo(swhere); 4 string colorStr = ""; 5 StringBuilder rowHt

重构笔记——代码的坏味道(上)

在重构入门篇中,简单地介绍了重构的定义.为何重构.何时重构等.我想对于重构是如何运作的,你已经有了较好的理解了.但是对于代码中的坏味道,你可能 知道的并不多.坏味道可能是无形中产生的,也可能是开发人员偷懒造成的,还可能是其它某些因素导致的.不管怎么样,代码中的坏味道对程序没有半点好处,它 会促使程序腐烂,甚至变质.对于开发人员,真的是很有必要对这些坏味道进行了解和熟悉,理解它们产生的场景.针对当前程序,发现坏味道,对代码进行重构, 以消除坏味道,提高代码质量,提高自己水平. 下面让我们一起来熟悉

重构摘要3_代码的坏味道

如果尿布臭了,就换掉它. 1.Duplicated Code 重复代码 Extract Method Pull Up Method Form Template Method --> Template Method 模式 Substitute Algorithm --> 函数算法替代 2.Long Method 过长的函数 "间接层"所带来的全部利益--解释能力.共享能力.选择能力--都是有小函数支持的. 真正关键在于一个好名字. 每当感觉需要以注释来说明点什么的时候,我们就

代码的坏味道之二——译自《重构》

巨型类 当一个类尝试做的太多,它常常展示出过多的实例变量.当一个类有太多实例变量,重复代码的出现就不远了. 你可以提取类来打包一部分变量.选择在部件中有意义的变量放在一起.例如,“存款总量”和“存款货币”很可能在同一部件中.更宽泛的说,在一个类中变量的某个子集共同的前缀和后缀预示着组成同一个部件的机会.如果这个部件有成为子类的意义,你会发现提取子类往往更容易. 有时一个类不会一直使用它全部的实例变量.如果如此,你可能可以提取类或者提取子类若干次. 相比于一个类有太多实例变量,一个类有太多代码是重

代码的坏味道之五 ——译自《重构》

夸夸其谈未来性Speculative Generality Brian Foote 为一个我们都很敏感的味道建议的名字.你会遇到它当有人说“哦,我认为我们某一天会需要能力去做那一类的事”然后这样一来希望得到各种钓钩和特别的例子去处理并不需要的事情.结果往往是更难懂也难维护.如果所有的这些机制被用上,那这样做还是值得的.如果不是这样,也就不值得.这个机制就是这样产生的,所以处理掉它. 如果你有抽象类并没有做很多事,用Collapse Hierarchy.不必要的委托可以用Inline Class去

代码的坏味道之三——译自《重构》

散弹式修改(Shotgun Surgery) 散弹式修改和发散式变化类似,但却相反.每当你做一种修改你却必须对很多不同的类做很多小的变化,你面临的就是散弹式修改.当变化到处都是时,有的变化就不好找到了,这样很容易漏掉重要的更改. 这种情况下你要使用移动方法(Move Method)和移动字段(Move Field)来把所有的变化放到一个类里.如果没有现成的类合适,就创建一个类.通常你会用到内联化类(Inline Class)把一系列行为放到一起.你会有一点发散式变化的问题,但你可以轻松处理它.

代码的坏味道之四 ——译自《重构》

基本类型偏执Primitive Obsession 大多数编程环境有两种类型的数据.记录类型允许你把数据结构化成有意义的集合.基本类型是你建设用的砖块.记录类型总是会产生一定量的额外开销.这可能是数据库中的表,或者被很尴尬的创建当你希望他们只为一或两件东西存在. 关于对象一个很有意义的东西是,他们模糊甚至打破了基本类型和大型类之间的界线.你可以很轻松的写小的无法和语言中内建类型相区别的类.Java对数字有基本类型,但字符和日期这些在其他环境也是基本类型的,在Java里是类. 新接触对象的人通常不

代码的坏味道之一——译自《重构》

重复代码 臭味集合里面排第一的就是重复代码了.如果你在不止一处发现了同样结构的代码,你可以确定如果你找到一种方法来统一他们的话,你的程序将会改善. 最简单的重复代码问题是当你在同一个类中有两个方法有相同的表达时出现的.那么你需要做的所有步骤只是提取方法然后在两处调用代码. 另一种常见的重复问题是当你在两个兄弟类中有相同的表达.你可以通过在两个类中提取方法然后拉升方法(Pull up Method)来消灭重复.如果这段代码相似但不相同,你需要通过提取方法来分离相同和不同的部分.你可能会发现你可以使

实例说明什么是代码的坏味道,如何重构

所谓优雅的代码,或者恶心的代码,很多时候是见仁见智的.也同时是看个人喜好或者习惯的.当经验不足,看的和写的代码还不够多的时候,我们可能会追捧某个大神或者奉某本经典为圭臬.然后跟学校的学弟们说,有空多看看<重构>和<设计模式>吧. 在我看来,优雅的代码并不是说这个代码写的有多神,多么让人惊叹.能够让人清晰的去阅读去理解就是好的代码.代码并不是艺术,更多的是严谨的表达出自己的思路.在这个过程中代码的易读性是第一位的,然后是正确性,然后是运行效率. 让人感到恼火的代码也并一定是写的多么凌