如何写出整洁的代码 上

• 1.为什么要保持代码整洁?

• 1.1 所以从一开始就要保持整洁
• 1.2 如何写出整洁的代码?

• 2.命名

• 2.1 不好的命名方式

• 3.类

• 3.1单一职责
• 3.2 开闭原则
• 3.3 内聚

• 4.函数

• 4.1 只做一件事
• 4.2 函数命名
• 4.3 参数
• 4.4 返回值
• 4.5 怎样写出这样的函数?
• 4.6 代码质量扫描工具

• 5.测试

• 5.1 TDD
• 5.2 FIRST原则
• 5.3 测试代码模式
• 5.4 自动生成单测

• 6.结束语

工作多年后，越发觉得代码整洁真的是太重要了！尤其是在团队开发中，写出优雅工整的代码，能让同事更乐于跟你合作。

下面，将通过命名、类、函数、测试这四个章节,使我们的代码变得整洁。

1.为什么要保持代码整洁?

不整洁的代码随着时间的增加而增加时,生产力会随之降低. 导致的结果就是:

• 代码不易扩展或扩展容易引发其他问题
• 程序崩溃
• 加班
• 增加公司成本(加人) 甚至可能造成公司倒闭 一图胜千言

1.1 所以从一开始就要保持整洁

所以在一开始就要写整洁的代码,如果有不整洁的代码就要及时的整改. 绝对不要有以后再改,以后再说的想法， 因为！

later equal never

想想是不是这个道理,你有多少以后再说、以后再改的东西都抛诸脑后了.

如果是一定要做的事情,那就趁早做!

1.2 如何写出整洁的代码?

那么现在的问题就是,怎样的代码才算是整洁的代码呢:

• 可读性要高: 代码要像散文一样优雅易读,见码知意
  
• 拒绝重复代码
  
• 满足设计模式原则
  

• 单一职责
• 开闭原则
• 里氏替换原则
• 依赖倒转原则
• 接口隔离原则
• 迪米特法则
• 合成复用法则

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

2.命名

好的命名可提高代码的可读性,让人见码知意, 降低理解成本,提高效率, 减少加班.

2.1 不好的命名方式

1. 没有任何意义的命名方式

public interface Animal {
    void abc();
}

现在我们有一个动物的接口, 里面有一个方法abc(),看了让人一头雾水, 调用这个方法的人也完全不知道这个方法是干什么的,因为他的命名毫无意义

有意义的命名方式:

public interface Animal {
    void cry();
}

我们将方法名命名为cry(喊叫,呼喊),调用的人就知道这个方法的作用是什么了.

所以命名一定要有意义且让人见码知意.

2. 命名前后不一致 这种情况体现在明明是同一行为,但是却有不同的命名,前后不一致,让人造成混淆.

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(
            @Param("id") String id
    );
    List<Student> queryAllStudent(
    );
}

上面两个方法都是查询 xxx, 但是命名一会叫 query 一会叫 find,这种情况应该加以规范,保持一致, 修改后:

public interface StudentRepository extends JpaRepository<AlertAll, String> {
    Student findOneById(
            @Param("id") String id
    );
    List<Student> findAll(
    );
}

3. 命名冗余 体现在命名有很多没必要的成分在里面, 并且这些"废话"并不能帮助区分它们的区别, 例如在变量命名中添加了 Variable 这个词, 在表名中添加了 Table 这个词.所以命名中不要出现冗余的单词 , 并且提前约定好命名的规范.

// 获取单个对象的方法用get做前缀
getXxx();
//获取多个对象用list做前缀
listXxxx();

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

3.类

整洁的类应满足一下内容:

• 单一职责
• 开闭原则
• 高内聚性

3.1单一职责

类应该短小,类或模块应有且只有一条加以修改的理由 , 如果一个类过于庞大的话,那么说明它承担的职责过多了.

优点:

• 降低类的复杂度
• 提高类的可读性
• 提高系统的可维护性
• 降低变更引起的风险

如何判定类是否足够短小?

通过计算类的职责来判断是否够短小,类的名称描述其全责, 如果无法为某个类命以准确的名称, 这个类大概就太长了, 类名越含糊,可能拥有越多的职责.

职责过多的例子,可以看到以下类有两个职责:

public abstract class Sql {
    // 操作SQL的职责
    public abstract void insert();
    // 统计SQL操作的职责
    public abstract void countInsert();
}

将统计的职责抽取到另一个类

public abstract class CountSql {
    public abstract void countInsert();
}

3.2 开闭原则

开闭原则: 面向修改关闭, 面向扩展开放.

面向修改关闭意味着增加新的逻辑不会修改原有的代码,降低了出错的可能性.

面向扩展开放则是提高了代码的可扩展性,可很容易的增加新的代码逻辑.

不满足开闭原则的例子:

public abstract class Sql {
    public abstract void insert();
    public abstract void update();
    public abstract void delete();
}

如果我们现在要新增查询的操作,就需要修改Sql这个类,没有做到面向修改关闭

重构后:

public abstract class Sql {
    public abstract void generate();
}
public class CreateSql extends Sql {
    @java.lang.Override
    public void generate() {
        // 省略实现
    }
}
public class UpdateSql extends Sql {
    @Override
    public void generate() {
        // 省略实现
    }
}

当我们要增加删除方法时可以很容易的扩展.

使用大量的短小的类看似比使用少量庞大的类增加了工作量(增加了更多的类),但是真的是这样吗? 这里有一个很好的类比:

你是想把工具归置到有许多抽屉、每个抽屉中装有定义和标记良好的组件的工具箱呢, 还是想要少数几个能随便把所有东西扔进去的抽屉?

最终的结论:

系统应该由许多短小的类而不是少量巨大的类组成,每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为.

3.3 内聚

方法操作的变量越多,就越粘聚到类上. 如果一个类中的每个变量都被每个方法所使用, 则该类具有最大的内聚性. 我们应该将类的内聚性保持在较高的位置. 内聚性高意味着方法和变量互相依赖, 互相结合成一个逻辑整体.

为什么要保持高内聚? 保持内聚性就会得到许多短小的类,就越满足单一职责.

内聚性低怎么办? 如果类的内聚性就不够高,就将原有的类拆分为新的类和方法.