noneplus

“如果尿布臭了,就换掉它。”

——Beck奶奶,论保持小孩清洁的哲学


代码的坏味道这一章集中论述该何时重构。具体的重构方法在后面的章节。

“没有任何度量规矩比得上见识广博者的直觉。你必须培养自己的判断力,学会判断一个类中有多少实例变量才算太大,一个函数内有多少代码才不算太长。”

​ ——Martin Flower

3.1 改名

深思熟虑给函数,模块,变量和类命名,使其清晰的表明自己的功能和用法。

重构手法之一:改名(改变函数声明,变量改名,字段改名)

3.2 消除重复代码——提炼函数

同一个类的两个函数含有相同的表达式——提炼函数。

重复的代码段位于同一个超类的不同子类中——函数上移。

3.3 拆分过长函数

“活的最长,最好的程序往往都比较短”

“函数越长,就越难理解”

3.4 过长参数列表

  • 如果发现几项参数经常出现,可通过引入参数对象将其合并为一个对象。(封装)
  • 如果发现从现有的数据结构抽出很多数据项作为参数,不如直接传递完整的对象
  • 以查询替代参数:可以像某个参数查询获得另一个参数的值。

3.5 全局变量

全局变量的问题:代码库的任何一个角落都可以修改,且无法探测。(代码病毒)

处理方法:封装变量。用函数封装起来,再搬到类或模块里,控制其访问权限。

3.6 发散式变化与霰弹式修改

发散式变化:遇到变化时固定修改某一部分代码。

霰弹式修改:代码的坏味道其中一种,遇到变化需要修改很多地方。

减小模块的耦合,实现模块的独立。在添加修改功能时实现代码变更的独立。

3.7 依恋情节

模块化:最大化区域的内部交互,最小化的跨区域交互。

依恋情节:一个函数和另一个模块的函数或者数据交流格外频繁,远胜于在自己内部的交流。

3.8 数据泥团

"两个类中相同的字段,许多函数签名中相同的参数...."

在必要时提炼类。引入参数对象,保持对象完整使之参数列表较短。

语义和形式的权衡。

3.9 使用多态替换switch

3.10 循环语句

以管道取代循环。

3.11 冗赘的元素

随着重构类变得越来越小,适时庄严赴义。

3.12 夸夸其谈通用性

如果用不到,就不值得。用不上的装置只会挡路。

3.13 中间人

封装往往伴随着委托。

委托应当适度,过度委托就会变成冗余。

3.14 过大的类

造成重复代码。

提炼类,提炼超类。

3.15 注释

“当你感觉需要写注释时,请先尝试重构。”

注释的应用场景:

  • 这段代码做了什么
  • 记录将来的打算
  • 为什么做

分类:

技术点:

相关文章: