作者 | 雷架
来源 | 爱笑的架构师（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个条件就是上帝类：
CPFD (Capsules Providing Foreign Data) 从多个不相关类（模块）中引用数据。
WOC (Weighted Operation Count) 类的所有函数的圈复杂度之和超过65。
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 （简单设计原则）。
当实现当下业务代码时需要考虑四个原则：
通过测试
揭示意图
消除重复
最少元素。
当需要为未来而写的代码时，可以干这些：
删除那些觉得未来有用的参数、代码、方法调用。
修正方法名，使方法名揭示当下业务场景的意图，避免抽象的技术描述词。
如果代码的改动确实是未来必然会发现的，那么还是建议保留。夸夸其谈未来性更多是指开发人员无依据臆测未来，导致代码模块被过度设计。
Comments（过多的注释）
在 《Clean Code》 中列举了一些常见注释坏味道：
喃喃自语
多余的注释
误导性注释
循规方注释
日志式注释
废话注释
用注释来解释变量意思
用来标记位置的注释
类的归属的注释
注释掉的代码
为什么过多的注释是一种代码坏味道呢？
好的注释可以辅助开发人员快速阅读理解代码，过多的注释或坏注释可能会降低代码的可读性。
在开发实践中经常有同学修改了代码但是注释没有同步修改，代码的实现已经与注释内容不一致，容易产生误导。
如何解决过多的注释这种坏味道呢？
如果代码块不再使用请直接删除不要使用注释。
方法、变量的命名尽量见名知意，避免用注释再解释一遍。
如果较短的注释不能覆盖方法的含义，可能是这个方法职责不单一，可以考虑重构这个方法。
总结
文章列举了几种比较常见的代码坏味道，希望大家在工作编码中多多练习，争取人人都能写出好代码，让天下没有难读的代码。如果需要深入学习代码坏味道，推荐仔细研读两本书：《重构:改善既有代码的设计》，《Clean Code》。
更多精彩推荐
☞程序员有钱了都干什么？买豪宅，玩跑车，上太空！| 涛滔不绝
☞被微软称为 “世界的电脑” ，Azure 到底有多牛？
☞编写贩卖《和平精英》游戏外挂，5人被判刑；苹果推出轻App码；Firefox 84.0发布|极客头条☞赠书 | 实现病人数据自动分析建模，Python能做的比你想象得更多
☞我是Redis，MySQL大哥被我害惨了！
☞“刚毕业1年，做数据分析凭什么涨薪三连跳！”网友：吹的不多..
点分享点点赞点在看