优雅编程之这样重构代码,你就“正常”了(十八)

开心一笑

【老婆问老公:你喜欢玩水还是喜欢玩火?
老公:我喜欢玩火。
老婆:那以后,饭就由你来煮。
老公:不不不,我喜欢玩水。
老婆:那以后的碗就由你来洗。
老公:瞬间石化。…】

【男孩:我感动天,感动地,怎么感动………
女孩:你要是敢动我,我,我,我就打死你。
男孩:好好的一首情歌。……】

提出问题

项目开发中如何进行重构???

解决问题

优雅编程之这样重构代码,你就“正常”了(十八)_第1张图片
励志图片

这是《重构 改善既有代码的设计》中第15章我觉得比较重要的知识点。事实上只要看第1章的例子,第24章个人建议可以略过,没什么用.

重构的第一步

每当我要进行重构的时候,第一个步骤永远是相同的。即建立一个可靠的测试环境。

分解和重组

代码块越小,代码的功能就越容易管理,代码的处理和移动也就越轻松。

首先,我得在代码里找出函数内的局部变量和参数。任何不会被修改的变量,都可以被我当成参数传入新的函数,至于会被修改的变量,就需要格外的小心。

正和一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解代码才是优秀的程序员。

去除临时变量

利用多态取代

何为重构:

名词:重构,对软件内部结构的一种调整,目的是在不改变,软件可观察行为的前提下,提高其可理解性,降低其修改成本。

动词:重构,使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

两顶帽子

添加新功能以及重构。

添加新功能就添加新功能,先不要去重构,重构你就好好重构,先不要去添加新的功能。

为何重构

原因我就不说了,反正就他妈好。

何时重构

三次法则:第一次做某件事时只管去做,第二次做类似的事时会产生反感,但无论如何还是可以去做,第三次再做类似的事,你就应该重构。

  • 添加功能时重构
  • 修补错误时重构
  • 复审代码时重构

以下是一些坏代码味道:符合下面就该重构了

  • Duplicated Code(重复代码)

  • Long Method(过长函数)

  • Large Class(过大的类)

  • Long Parameter List(过长的参数列表)

  • Divergent Change(发散式变化):当你看着一个类说:如果新加入一个数据库,我必须修改这三个函数,如果新出现一种金融工具,我必须修改这四个函数。那么此时也许将这个对象分成两个会更好。

  • Shotgun Surgery(弹式修改):
    如果遇到哪种情况,你都必须在很多不同的类内作出,许多小修改。那就是坏的味道。这时候你需要把所有需要修改的代码放进同一个类。如果眼下没有合适的类可以安置这些代码,就创建一个。

  • Feature Envy(依恋情节)

函数对某个类的兴趣高过对自己所处类的兴趣,是时候考虑这个函数到底应该放在什么位置了。

对象技术的全部要点:这是一种将数据和对数据的操作行为包装在一起的技术。

最根本的原则是,将总是一起变化的东西放在一块。

数据和引用这些数据的行为总是一起变化的。

  • Data Clumps(数据泥团)

减少字段和参数的个数,当然可以去除一些坏味道。但更重要的是,一旦拥有新对象,你就有机会让程序散发出一种芳香。

  • Primitive Obsession(基本类型偏执)

将原本单独存在的数据值替换为对象,从而走出传统的洞窟,进入炙手可热的对象世界。

编写小对象,如表示范围的Range

  • Switch Statements(switch 惊悚现身)

面向对象程序的一个最明显特征:少用switch(或case)语句。

看到switch语句,就应该考虑以多态来替换它。

  • Parallel Inheritance Hierarchies(平行继承体系)

每当你为某个类添加一个子类,必须也为另一个类相应增加一个子类,大多数时候你会发现,某个继承体系的类名前缀和另一个继承体系的类名前缀完全相同。是时候分离,为两个继承体系了。

  • Lazy Class(冗赘类)

你所创建的每个类,都得有人去理解它,维护它,这些工作都是要花钱的。如果一个类的所得不值其所价,它就应该消失。

  • Speculative Generality(夸夸其谈未来性)

无用的抽象类,无用的预留参数。

  • Temporary Field(令人迷惑的暂时字段)

某个类的实例变量仅为某种特定情况来设,某个函数的参数,为了方便声明为某个类的成员,而仅仅在这一个函数中使用。

  • Message Chains(过度耦合的函数)

现一个对象请求另一个对象,在向后者请求另一个对象。

  • Middle Man(中间人)

你也许会看到某个类接口,有一半的函数都委托给其他类,这样就是过度运用。

无用的委托,过多的中间层。

  • Inappropriate Intimacy(钾昵关系)

类不要过度亲密,一个类过一关注另一个类的成员。

  • Alternative Classes with Different Interfaces(曲同工的类)

两个函数做同一件事,却有着不同的类名

  • Incomplete Library Class(不完美的类库)

  • Data Class(纯稚的数据类)

或许可以通过移动方法把和这个数据对相关的操作一过来。

  • Refused Bequest(被拒绝的遗赠)

  • Comments(过多的注释)

读书感悟

来自几米《月亮忘记了》

  • 每个人都有一个像月亮一样的爱人,因为这个爱人,我们拥有守护的能力。

  • 记住的,是不是永远不会消失? 我守护如泡沫般脆弱的梦境, 快乐才刚开始,悲伤却早已潜伏而来。

  • 生命中,不断地有得到和失落。于是,看不见的,看见了;遗忘的,记住了。
    生命中,不断地有人离开或进入。于是,看见的,看不见了;记住的,遗忘了。
    然而,看不见的,是不是就等于不存在?记住的,是不是就不会消失?

其他

如果有带给你一丝丝小快乐,就让快乐继续传递下去,欢迎转载,点赞,顶,欢迎留下宝贵的意见,多谢支持!

你可能感兴趣的:(优雅编程之这样重构代码,你就“正常”了(十八))