Martin Fowler：任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。 大家闭着眼睛想一下什么是好代码？也许你的脑海中漂浮着一堆词：干净、整洁、命名规范、注释合理、高内聚低耦合…… 人人都想写好代码，因为看好代码就如同看一位五官端正的女子，心情愉悦、舒畅，而看糟糕的代码就如同看见腐烂的食物，闻起来也有一股坏味道。 大多数人写的代码都不能称之为好代码，一方面由于自己技能限制，另一方面也可能根本就分不清好代码和坏代码，下面笔者结合日常编码实践与大家分享一下常见的代码坏味道。
坏味道：Long Method（过长函数）
过长函数简而言之就是函数长度超标了，包括横向和纵向。 为什么过长函数是一种坏味道？ 横向过长会导致无法一眼就能看出这行代码的作用，需要用鼠标慢慢往后边拖，相信用小屏幕的小伙伴经常会遇到这个问题，拖动的过程会严重影响读代码的效率。 纵向过长其实就是出现了大函数，一个函数的行太多，使得函数难以读懂，代码修改难度大。 那么如何解决过长函数问题呢？ 关于横向过长的问题，一般会在 IDE 中提前配置好最大宽度，比如80字符或者120字符（具体根据公司内部规范设置），然后格式化代码即可解决。 比如我们在写 Java8 stream 链式表达式的时候可以会很长： List nodes = list.stream().filter().filter().map.filter().collect(Collectors.toList()); // 可能会非常长 其实我们可以在.之前换行，这样看起来一目了然。 List 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：依赖倒置原则 六个原则的首字母联合起来就是 SOLID，两个 L 当成一个。 那如何判断一个类是不是上帝类呢？ 一般一个类同时满足以下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（重复代码）
Robert C.Martin：重复可能是软件中一切邪恶的根源。 重复代码一般是由于复制粘贴造成的。需求迭代过程中为了不影响已有功能，通常是将之前的代码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）修正方法名，使方法名揭示当下业务场景的意图，避免抽象的技术描述词。 如果代码的改动确实是未来必然会发现的，那么还是建议保留。夸夸其谈未来性更多是指开发人员无依据臆测未来，导致代码模块被过度设计。
坏味道：Comments（过多的注释）
在 《Clean Code》 中列举了一些常见注释坏味道： 喃喃自语 多余的注释 误导性注释 循规方注释 日志式注释 废话注释 用注释来解释变量意思 用来标记位置的注释 类的归属的注释 注释掉的代码 为什么过多的注释是一种代码坏味道呢？ 好的注释可以辅助开发人员快速阅读理解代码，过多的注释或坏注释可能会降低代码的可读性。 在开发实践中经常有同学修改了代码但是注释没有同步修改，代码的实现已经与注释内容不一致，容易产生误导。 如何解决过多的注释这种坏味道呢？ （1）如果代码块不再使用请直接删除不要使用注释。 （2）方法、变量的命名尽量见名知意，避免用注释再解释一遍。 （3）如果较短的注释不能覆盖方法的含义，可能是这个方法职责不单一，可以考虑重构这个方法。
总结：
文章列举了几种比较常见的代码坏味道，希望大家在工作编码中多多练习，争取人人都能写出好代码，让天下没有难读的代码。如果需要深入学习代码坏味道，推荐仔细研读两本书：《重构:改善既有代码的设计》，《Clean Code》。
