何为“坏代码”？浅谈

83 阅读 0 评论 55 点赞

我是靠谱客的博主着急水蜜桃，最近开发中收集的这篇文章主要介绍何为“坏代码”？浅谈，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、重复的代码
重复代码就是不同的地方有着相同的程序结构。重复代码很难维护的，如果你要修改其中一段的代码逻辑，就需要修改多次，很可能出现遗漏的情况。
优化方法：若是同一个类中两个方法含有相同的代码块，可以抽出重复的代码，组成一个公用的方法。若是两个互为兄弟的子类内含有相同的代码块，可以抽出到父类中，组成一个方法。若是两个毫不相干的类含有相同的代码块，可以提取整合到一个类中。
2、长函数
长函数是指一个方法中代码几百行甚至更多，可读性大大降低，不便于理解。
优化方法：抽取功能单一的代码块，组成命名清晰的小方法，就可以解决长函数的问题。
3、过长的类
一个类做了大多事情，又当妈又当爸，可读性变差，性能也会下降。试想若是乱七八糟的代码块都往一个类中写，还谈啥可读性，应该遵守职责单一原则。
优化方法：解耦成单一职责的小类。
4、过长的参数
方法中的参数数量过多的话，可读性很差，若有多个重载方法，参数很多，有时候自己都不知道调用那个。
优化方法：将参数封装成结构或单独的类，如将参数封装成一个DTO类。
5、分散式修改
当你实现某个小功能时，需要修改很多不同的类完成。
优化方法：将各个修改的地方集中到一起，抽象成一个新类。
6、数据泥团
所有的字段都放在一个类中。
优化方法：若是一些数据字段总是一起出现，并且一起是有意义的，就可以将其封装成数据对象。
7、switch语句
switch语句或者if else语句，如果需要新添加一个新的case语句，就必须找到所有的switch语句并修改他们。
优化方法：可以参考使用多态，定义一个接口，多个不同的实现类。
8、冗余类
如应用中已经有日期工具类DataUtil了，有些小伙伴在开发中，需要用到日期转换功能，不管三七二十一，又自己实现了一个新的日期工具类。
优化方法：提炼到统一的工具类中。
9、过多的注释
这个点不是说代码不建议写注释哦，而是，建议大家避免用注释解释代码，避免过多的注释。这些都是常见注释的坏味道：多余的解释、日志式注释、用注释解释变量等。
优化方法：方法函数、变量的命名要规范、浅显易懂、避免用注释解释代码。
关键、复杂的业务，使用清晰、简明的注释
10、神奇命名
方法函数、变量、类名、模块等，都需要简单明了，浅显易懂。避免靠自己主观意识瞎起名字。
11、神奇魔法数
日常开发中，经常会遇到这种代码：

if(userType==1){
   //doSth1
}else If( userType ==2){
   //doSth2
}
...

优化方法：新建个常量类，把一些常量放进去，统一管理，并且写好注释；或建一个枚举类，把相关的魔法数字放到一起管理。
12、混乱的代码层次调用
每一层做每一层的事情，如controller调用service，service调dao。如果你在代码看到controller直接调用dao，那可以考虑是否优化啦。
dao层主要做数据持久层的工作，与数据库打交道。service层主要负责业务逻辑处理。controller层负责具体的业务模块流程的控制。