新来的同事不会用 Lombok，所以会引发本文！
背景
最近公司新来一个高 Java 的同事，搞了半天项目还没有跑起来，后来叫我过去帮他看一下，然后指着红色的编译错误和我说是不是代码有问题。。
我顿时就心想，这人是不是太水了啊，工作三年了，简单的编译问题都搞不定？但是当我认真看了错误之后，发现……他竟然没装 Lombok 插件……
然后我和他说出了问题所在，让他安装下 Lombok 插件再重新编译下，他居然和我说不知道什么插件，感觉他没用过吧，甚至都没有听说过。
好吧，我认了，我默默亲自为他把 Lombok 装上了！
如果你没用过，我也不觉得奇怪，Lombok 毕竟是团队工具，但如果你也没听过，那就感觉获取新知识自我提升学习的能力有点弱了。
当然，本篇不是教你怎么用 Lombok，因为我之前就已经写过教程分享过了，不会的可以点击这个链接看下，还热乎着呢。
放弃 Lombok？
因为，最近也有看到一些公众号在发放弃 Lombok 的文章，再结合最近一个新同事的情况，也谈谈到底要不要用 Lombok。
一味地让大家放弃，我感觉有点偏激了，任何事物，存在就即合理，关键是利弊权衡的问题罢了。
用不用 Lombok，又是分两派，公说公有理，婆说婆有理，仁者见仁，智者见智，谁也说服不了谁，类似 Eclipse 和 IntelliJ IDEA 谁更好用之争！
我想说，争这些没任何意义，这完全取决于团队的决策，取决于你的团队能不能 Hold 住这个东西，如果利 > 弊，用它就对了，如果弊 > 利，那就考虑放弃吧。
如果你是个人项目，请大胆用吧！
Lombok 的弊端
Lombok 的好处就不说了，就是帮我们大量简化代码，这里重点说下为什么有人不推荐使用 Lombok。
一、需要额外的组件
使用 Lombok 需要两个必要的组件：
1）Lombok 依赖包
使用 Lombok 的注解，就必须引用它的依赖，最后编译成最终的 class 类，如 Maven 依赖示例：
org.projectlombok
lombok
1.18.12
provided
这个不会引起问题，因为它是代码的一部分，而且在项目一开始的时候就引入进去了。
2）Lombok IDE 插件
Eclipse/ IntelliJ IDEA 都提供了 Lombok 插件，用来识别 Lombok 的注解，否则会显示编译报错。
IntelliJ IDEA 插件示例：
如果某一个人为了方便自己而使用，其他人不愿意使用或者被迫使用，将导致团队其他成员代码没法正常编译，这也是问题的关键所在。
还有就是文章之前说的，来了一个新同事，如果他没有相应的使用经验，就需要额外的指导，对于老员工来说无疑也是一个额外的工作量。
二、@Data 注解的坑
@Data 注解用在类上，等同于下面这几个注解合集：
@Getter
@Setter
@RequiredArgsConstructor
@ToString
@EqualsAndHashCode
@Getter, @Setter, @ToString 很简单，用起来也没问题，而 @RequiredArgsConstructor和 @EqualsAndHashCode 需要注意下。
1）RequiredArgsConstructor
Generates a constructor with required arguments.Required arguments are final fields and fields with constraints such as {@code @NonNull}.
即生成一个类构造器，参数包含所有用 final 修饰、以及 @NonNull 注解修饰的变量。
如果参数很多，都在一个构造器里面，一、极不优雅，可读性很差，二、不良设计。
与这个注解相关的还有 AllArgsConstructor 注解，包括所有参数，还是小心为妙。但在参数不多的时候还是可以代替使用的，但对不熟悉的人来说就是个潜在的问题。
2）@EqualsAndHashCode
Generates implementations for the {@code equals} and {@code hashCode} methods inherited by all objects, based on relevant fields.
这个注解用来生成 equals 和 hashCode 方法，里面有一个 callSuper() 方法：
/**
* Call on the superclass's implementations of {@codeequals} and {@codehashCode} before calculating for the fields in this class.
* <strong>default: false</strong>
*
*@returnWhether to call the superclass's {@codeequals} implementation as part of the generated equals algorithm.
*/
booleancallSuper()defaultfalse;
是否调用父类的 equals 和 hashCode 方法，默认为：false 不调用，这也是引起问题的关键。
来看下面的例子：
@Data
publicclassBaseStudent{
privateintid;
}
@Data
@AllArgsConstructor
publicclassStudentextendsBaseStudent{
privateString name;
privateintage;
privateString address;
}
把生成的 equals 和 hashCode 方法反编译出来看下：
publicboolean equals(Object o) {
if(o ==this)
returntrue;
if(!(o instanceof Student))
returnfalse;
Student other = (Student)o;
if(!other.canEqual(this))
returnfalse;
Objectthis$name = getName(), other$name = other.getName();
if((this$name ==null) ? (other$name !=null) : !this$name.equals(other$name))
returnfalse;
if(getAge() != other.getAge())
returnfalse;
Objectthis$address = getAddress(), other$address = other.getAddress();
return!((this$address ==null) ? (other$address !=null) : !this$address.equals(other$address));
}
publicint hashCode() {
int PRIME =59;
result =1;
Object $name = getName();
result = result *59+ (($name ==null) ?43: $name.hashCode());
result = result *59+ getAge();
Object $address = getAddress();
returnresult *59+ (($address ==null) ?43: $address.hashCode());
}
最后判断如果不是同一个对象时，会判断每个变量的值，但是此时父类的值不参与比较，这显然是不符合逻辑的，另外 hashCode 方法父类的值也没有参与运算，也是潜在问题。
三、代码跟踪调试
使用 Lombok 可以帮助我们少写很多代码，但同时也降低了代码可读性和跟踪、调试的问题。
比如，我想查找 getName() 方法都被哪些地方引用了，就不能直接按快捷键了，可能需要费一翻力气。
代码调试也有问题，比如我跟进 getAddress 方法，虽然进不去该方法，但可以直接跳到对应的变量，显示对应的值。
但是我想调试生成后的 hashCode 方法的运算过程，代码没有，断点都没法打，怎么调试？
即使如此，我觉得这个问题不大，我们很少去跟踪这些代码，我们也可以通过其他方式来曲线解决。
总结
以上一些问题都是使用 Lombok 不可避免的，这还只是已知的问题，未知的呢？
Lombok 虽好，你也要遵循团队的规范，能用的情况下再用，也不能乱用，不了解其构造，乱用就容易出现问题的。
最好的方法是，作用域最小化，需要什么就用什么，注解单独使用，而不是三七二十一什么类上来都来一个 @Data 什么的，出问题就欲哭无泪了。
所有种种潜在的问题都是领导者不愿意看到的，所以，有的公司是明令禁止使用 Lombok的，我个人是不沾边，适度运用就好，但不要过度依赖。
如果你还遇到其他使用 Lombok 的问题，欢迎留言分享~
网友评论