封面来源:本文封面来源于网络,如有侵权,请联系删除。

1. 一些小感悟

进入公司有将近一个月了,一个月下来就是熟悉业务,写写小 demo,感觉与在校学习也没什么两样,直到考核,或者说测试。经过这次测试,我也深刻认识到了公司和学校的不同。

在学校里,不同的老师对于作业的检查力度是不一样的,一个严格的老师,或许会抠每个字眼,但是如果遇到不怎么负责的老师,作业的检查可能也就走个形式,也不管你内容如何、质量如何。

在公司里,每个人都是为了给公司创造价值,需要更严格地要求自己,让自己在公司的所做所为能够为公司带来价值和收益。

还有很肤浅的一点区别,进学校,你要给学校钱,进公司,公司会给你钱。学校从你这里赚钱(虽然也赚不到啥),学校并不要求你能对学校产生多少价值;但是进公司,公司会给你钱,公司就要求你能产生更多的价值,从而某些要求就会更加严格。

总的来说,在公司里,自己得对自己要求严格,不仅为了自己以后的前程,也为了在当前公司内能过的舒坦,谁也不想每天一到公司就被说这说那吧。

2. 考核过程的错误

2.1 注释不规范

Java 中有三种注释方式,单行注释、块注释和文档注释。

单行注释一次只能注释一行,一般是简单的注释,用来简短描述某个变量、属性或程序块。

块注释是为了进行多行简单注释,一般不使用。

文档注释一般用来对 类、接口、成员方法、成员变量、静态字段、静态方法和常量 进行说明,Java Doc 可以用它来产生代码的文档,为了可读性,可以有缩进和格式控制。文档注释还可以采用一些 Java Doc 标签进行文档的特定用途描述,用于帮助产生 Java Doc 文档,常用的有:@author@Description@Param 等等。

在今天的考核中,我在方法上使用了单行注释,这显然是不规范,应该使用文档注释。

2.2 缓存使用

需要特别注意的是: 缓存可能会丢失!

2.3 Objects.requireNonNull()

该方法的源码是这样的:

1
2
3
4
5
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}

这个方法很简单,如果当前对象为空就抛出异常,否则返回当前对象。那这样一个方法有啥用呢?就算对象为空而没有使用这个方法,也会抛出异常啊?这不是多此一举吗?

这里涉及一种编程思想 —— Fail-fast (快速失败)思想,简单来说,就是让错误尽可能早的出现,不要等到我们很多工作执行到一半之后才抛出异常,这样很可能使得一部分变量处于异常状态,出现更多的错误。这也是 requireNonNull() 这个方法的设计思想,让错误尽早出现,使用这个方法,我们明确的抛出异常,发生错误时,我们立刻抛出异常。

requireNonNull() 方法还有一个重载方法,可以提供一个报错信息,以供我们 debug 的时候显示。

1
2
3
4
5
public static <T> T requireNonNull(T obj, String message) {
if (obj == null)
throw new NullPointerException(message);
return obj;
}

通过这个方法,抛出一个明确异常,如果运行时出现问题,可以很方便的进行 debug 和排查。

简单来说,这个方法有三个用途:

1、控制行为,这个方法规定了某个对象不能为空,否则就会抛出异常

2、方便调试,因为提供了一个重载方法,使用这个重载方法就可以在出现异常时提供一个报错信息,以便我们 DeBug 显示。使用这个方法检查传入引用,可以控制引发异常的时间点,达到快速失败。同时如果调用栈很深,等到报异常时候都不知道是从哪里传过来的了,使用此方法就可以规避。

3、由于我们控制了传入引用在这方法后一定不为空,因此在后续不需要再进行判空。

参考链接:

使用Objects.requireNonNull判断一个对象是否为空吧

Why should one use Objects.requireNonNull()?

2.4 事务的控制

对某些方法进行事务控制时,可以在类上使用 @Transactional 注解,使用了这个注解后,可以对这个类中的增加、删除和修改方法进行事务控制。

但是如果这个类中有查询方法,为了更高的效率,需要在这些查询方法上使用:

1
@Transactional(readOnly = true)

2.5 项目的启动

一个项目的成功启动,应该依靠空库,不能依赖数据库存在初始数据才能启动成功。

2.6 单元测试

一个成功的单元测试应该是任何时候的测试结果都是一样的,无论是否空库都应该一样。

同时,每个单元测试方法之间不能有依赖,方法之间存在依赖不是一个合格的单元测试。

编写单元测试应该是在业务编写前就进行单元测试,后续编写会增加不必要的负担。

使用 IDEA 进行本地单元测试时,可以使用 Coverage 插件,使用这个插件后,要保证行覆盖率达到 99%,分支覆盖率达到 100%。

2.6 DTO 的使用

DTO(Data Transfer Object):数据传输对象,在项目中的业务层应当使用 DTO 来传递数据,而不是 POJO。

如果一个 POJO 有 8 个字段,在业务层的方法 A 需要使用 4 个字段,在方法 B 中需要使用另外 4 个字段,那么我们编写两个 DTO。

Java 中还有很多 O,这张图或许可以帮助理解:

各种O

3. 总结

这次的测试结果很不理想,自己需要提升的地方还有很多,还需要更加努力的学习,不要显摆自己的小聪明或小知识,这点小聪明在别人眼里可能就像小丑在跳舞一样。🤡

铭记下面这几句话:

1、知者不博,博者不知

2、真正的大师永远都怀着一颗学徒的心