不讲码德!坏味道偷袭我这个老码农

允我心安 提交于 2020-12-18 13:18:03


作者 | 雷架

来源 | 爱笑的架构师(ID:DancingOnYourCode)

大家闭上眼睛想一下什么是好代码?也许你的脑海中漂浮着一堆词:干净、整洁、命名规范、注释合理、高内聚低耦合……

人人都想写好代码,因为看好的代码就如同看一位五官端正的女子,会心情愉悦、舒畅;而看糟糕的代码就如同看见腐烂的食物,闻起来也有一股坏味道。

大多数人写的代码不能被称为好代码有两个原因,一是由于自身技能限制,二是很可能他们根本就分不清好代码和坏代码的区别。

本文,笔者将结合日常编码实践,与大家分享一下常见的代码坏味道。


Long Method(过长函数)

过长函数,简而言之就是函数长度超标了,包括横向和纵向。

为什么过长函数是一种坏味道?

横向过长会导致无法一眼就能看出这行代码的作用,需要用鼠标慢慢往后边拖,相信用小屏幕的小伙伴经常会遇到这个问题,拖动的过程会严重影响读代码的效率。

纵向过长其实就是出现了大函数,一个函数的行太多,使得函数难以读懂,代码修改难度大。

那么如何解决过长函数问题呢?

关于横向过长的问题,一般会在 IDE 中提前配置好最大宽度,比如80字符或者120字符(具体根据公司内部规范设置),然后格式化代码即可解决。

比如我们在写 Java8 stream链式表达式的时候可以会很长:

List<String> nodes = list.stream().filter().filter().map.filter().collect(Collectors.toList()); // 可能会非常长

其实我们可以在“.”之前换行,这样看起来就一目了然。

List<String> nodes = list.stream()
  .filter()
  .filter()
  .map
  .filter()
  .collect(Collectors.toList());

关于纵向过长的问题其实就是这个方法或者函数职责不够单一,一个函数中堆积太多功能。

重构的手段很简单:Extract Method,积极抽取函数或方法,隐藏细节保持职责单一


Large Class(过大的类)

过大的类也常常被称为上帝类(God Class),上帝类一般是指维护了太多功能(违反单一职责原则),连上帝也看不懂你的代码。

设计模式的六大原则有:

  • Single Responsibility Principle:单一职责原则

  • Open Closed Principle:开闭原则

  • Liskov Substitution Principle:里氏替换原则

  • Law of Demeter:迪米特法则

  • Interface Segregation Principle:接口隔离原则

  • Dependence Inversion Principle:依赖倒置原则

那如何判断一个类是不是上帝类呢?

一般一个类同时满足以下3个条件就是上帝类:

  1. CPFD (Capsules Providing Foreign Data) 从多个不相关类(模块)中引用数据。

  2. WOC (Weighted Operation Count) 类的所有函数的圈复杂度之和超过65。

  3. TCC (Tight Capsule Cohesion) TCC < 1/3 类需要具有低内聚的特性(类中直接相关的方法与全部方法之比小于1/3),也就是较少的private方法。

为什么过大的类是一种坏味道?

过大的类承担了过多的职责,往往有很多重复代码,并且这些重复代码你还不容易发现,这基本就是坏味道的开始。

过大的类被子类继承会导致其他坏味道,比如遗留的馈赠。

如何解决过大的类这种问题呢?

通过观察这个过大类的属性,看有没有一些属性有关联,如果有可以使用 Extract Class 将这些关联属性抽象到一个新类中,并将与这些属性相关的操作都 Move 到新的类中。

通过观察这个过大类的方法,看有没有一些函数或方法存在兄弟关联,如果有可以使用 Extract Subclass(提炼子类)的手段将这些方法提炼到子类中,子类可以继承父类。将相似的行为方法聚集在一个类中拆分到多个类中,可以进一步将发放调用解耦开。

以上方法循环往复,一个大类就可以拆分为多个小的且职责单一的类。


Duplicated Code(重复代码)

重复代码一般是由于复制粘贴造成的。需求迭代过程中为了不影响已有功能,通常是将之前的代码 copy 一份修改,然后匆匆上线。

那为什么重复的代码是一种坏味道呢?

最直接的弊端就是如果你想修改一段代码逻辑,可能会遗漏,甚至需要多次修改才能确保全部修改完。

如何解决重复代码的问题?

下面结合代码实践分几个场景分别描述。

场景1:同一个类中两个方法含有相同的表达式

class A {
    public void method1() {
        logic1
        logic2
        logic3
    }
    public void method2() {
        logic1
        logic2
        logic4
    }
}

重构手段:将两个方法共同的逻辑抽象出来。

重构后:

class A {
    public void method1() {
        baseMethod();
        logic3
    }
    public void method2() {
        baseMethod();
        logic4
    }
    public void baseMethod() {
        logic1
        logic2
    }
}

场景2:两个具有相同父类的子类内含有相同的表达式类 A 中有一个 method1,有三段逻辑。

class A extend Base {
    public void method1() {
        logic1
        logic2
        logic3
    }
}

类 B 中有一个 method2,也有三段逻辑。

class B extend Base {
    public void method2() {
        logic1
        logic2
        logic3
    }
}

重构手段:将重复代码抽象成一个方法放在父类中,差异部分由子类各自实现。

重构后:

class Base {
    public void baseMethod() {
        logic1
        logic2
    }
}
class A extend Base {
    public void method1() {
        baseMethod();
        logic3
    }
}
class B extend Base {
    public void method2() {
        baseMethod();
        logic3
    }
}

场景3:两个毫无相关的类出现重复代码

如果两个没有直接关联的类出现重复代码,可以考虑将重复的代码抽象到一个独立的普通类或者工具类中,适用方可以使用组合的方式调用。

代码样例这里不再赘述,与场景1和2大同小异,相信聪明的你一定能明白。


Long Parameter List(过长参数列)

全局变量是个邪恶的东西。数据是共享的,并且每个线程都可以修改,太多了容易导致程序不可控,所以大家喜欢将变量以行参的方式传递,久而久之参数列越来越长了。

为什么过长参数列是一种坏味道?

方法参数的数量太多会导致代码可读性非常差。如果有多个重载方法它们的方法参数都非常多,在写代码时很难判断该调用哪一个。

当一个方法需要新增功能,每次都可能会新增一个方法参数,这样导致调用方每次都要重新适配,小心被打哦,耗子尾汁。

如何解决过长参数列这种坏味道?

可以将多个参数封装到一个 DTO 对象中,方法间的对象通过对象的传输而不是过长的参数。

数据传输对象(DTO)(Data Transfer Object),是一种设计模式之间传输数据的软件应用系统。

特别需要提醒的是:有些情况下长参数也是合理的。因为使用参数可以避免某些依赖关系的产生。在编码实践中我们可以通过观察长参数的方法,如果这个方法经常变动那你就要考虑重构这个方法了。基本原则:事不过三,过三重构。


Shotgun Surgery(散弹式修改)

为什么散弹式修改是一种代码坏味道?

如果需要修改某个小功能,你需要在众多不同的类中做修改,首先很难找全,其次很可能会遗漏,这种问题一般称之为散弹式修改。

public class A {
    @Value("${db.mysql.url}")
    private String mysqlDbUrl;
}


public class B {
    @Value("${db.mysql.url}")
    private String mysqlDbUrl;
}

假如有多个类都使用了db.mysql.url这个变量,如果后面要将 mysql 切到 Oracle,那么可能会涉及到多处修改。如何解决散弹式修改这种代码坏味道呢?

可以使用 Move Method (搬移函数)和 Move Field (搬移字段)把所有需要修改的代码放进同1个类,如果暂时没有合适的类,就创建一个。


Speculative Generality(夸夸其谈未来性)

在工作中经常会听到有开发小伙伴说:昨天加班我将订单模块做了修改,未来可以……

听到这里你可以会鼓掌:牛叉啊,提前对功能模板预留了扩展性。但是不要急于故障,你看技术总监的脸黑着呢,为什么呢?这位小伙伴的代码可能是一种坏味道:夸夸其谈未来性。

为什么夸夸其谈未来性是一种代码坏味道?

互联网需求迭代更新速度快,”未来可以“意味着当下并不需要,有时候过度的抽象和预留扩展也会让系统难以理解,并且可能提前背上包袱往前走。

代码上总是谈未来可能性,会让团队陷入泥沼。每次有业务变动,开发人员都会考虑各种未来可能性,预留足够多的扩展接口,这无疑极大增加了代码复杂度,让一个可能快速上线的需求变得慢下来。

如何解决夸夸其谈未来性这种代码坏味道呢?

在代码架构设计中有一个原则叫:Simple Design (简单设计原则)。

当实现当下业务代码时需要考虑四个原则:

  1. 通过测试

  2. 揭示意图

  3. 消除重复

  4. 最少元素。

当需要为未来而写的代码时,可以干这些:

  1. 删除那些觉得未来有用的参数、代码、方法调用。

  2. 修正方法名,使方法名揭示当下业务场景的意图,避免抽象的技术描述词。

如果代码的改动确实是未来必然会发现的,那么还是建议保留。夸夸其谈未来性更多是指开发人员无依据臆测未来,导致代码模块被过度设计。


Comments(过多的注释)

在 《Clean Code》 中列举了一些常见注释坏味道:
喃喃自语
多余的注释
误导性注释
循规方注释
日志式注释
废话注释
用注释来解释变量意思
用来标记位置的注释
类的归属的注释
注释掉的代码









为什么过多的注释是一种代码坏味道呢?

好的注释可以辅助开发人员快速阅读理解代码,过多的注释或坏注释可能会降低代码的可读性。

在开发实践中经常有同学修改了代码但是注释没有同步修改,代码的实现已经与注释内容不一致,容易产生误导。

如何解决过多的注释这种坏味道呢?

  1. 如果代码块不再使用请直接删除不要使用注释。

  2. 方法、变量的命名尽量见名知意,避免用注释再解释一遍。

  3. 如果较短的注释不能覆盖方法的含义,可能是这个方法职责不单一,可以考虑重构这个方法。


总结

文章列举了几种比较常见的代码坏味道,希望大家在工作编码中多多练习,争取人人都能写出好代码,让天下没有难读的代码。如果需要深入学习代码坏味道,推荐仔细研读两本书:《重构:改善既有代码的设计》,《Clean Code》。


更多精彩推荐
☞程序员有钱了都干什么?买豪宅,玩跑车,上太空!| 涛滔不绝
☞被微软称为 “世界的电脑” ,Azure 到底有多牛?
☞编写贩卖《和平精英》游戏外挂,5人被判刑;苹果推出轻App码;Firefox 84.0发布|极客头条☞赠书 | 实现病人数据自动分析建模,Python能做的比你想象得更多

☞我是Redis,MySQL大哥被我害惨了!
☞“刚毕业1年,做数据分析凭什么涨薪三连跳!”网友:吹的不多..
点分享点点赞点在看

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!