我有个学弟，在一家小型互联网公司做Java后端开发，最近他们公司新来了一个技术总监，这位技术总监对技术细节很看重，一来公司之后就推出了很多"政策"，比如定义了很多开发规范、日志规范、甚至是要求大家统一使用某一款IDE。
但是这些都不是我这个学弟和我吐槽的点，他真正和我吐槽的是，他很不能理解，这位新来的技术总监竟然禁止公司内部所有开发使用Lombok。但是又没给出十分明确的，可以让人信服的理由。
于是他来找我聊天，问我这个要求到底是否合理。关于这个事情，我认为这位技术总监的出发点是好的，但是做法未免有些极端。
之所以说出发点是好的，是因为使用Lombok确实会带来很多问题，而且我个人在工作中也基本不主动使用。
之所以说不主动使用，那是因为有些同事的代码还是使用了的，所以我也被迫的要安装Lombok的插件。
既然聊到这个话题，就简单说说我的一些看法。
Lombok有什么好处？
Lombok是一款非常实用Java工具，可用来帮助开发人员消除Java的冗长代码，尤其是对于简单的Java对象（POJO）。它通过注释实现这一目的。
如果大家对于Lombok比较了解的话，可以先跳过这一段，直接往后看，如果不是很熟悉的话，可以简单了解一下。
想在项目中使用Lombok，需要三个步骤：
一、IDE中安装Lombok插件
目前Lombok支持多种IDE，其中包括主流的Eclips、Intellji IDEA、Myeclipse等都是支持的。
在IDEA中安装方式如下:
![-w400][1]
二、导入相关依赖
Lombok 支持使用多重构建工具进行导入依赖，目前主要支持maven、gardle、ant等均支持。
如使用maven导入方式如下：
<dependency>
<groupid>org.projectlombok/<groupid>
<artifactid>lombok/<artifactid>
<version>1.18.12/<version>
<scope>provided/<scope>
- 1
- 2
- 3
- 4
- 5
- 6
三、代码中使用注解
Lombok精简代码的方式主要是通过注解来实现，其中常用的有@Data、@Getter/@Setter、@Builder、@NonNull等。
如使用@Data注解，即可简单的定义一个Java Bean：
import lombok.Data;
@Data
public class Menu {
private String shopId;
private String skuMenuId;
private String skuName;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
使用@Data注解在类上，相当于同时使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor这些注解，对于POJO类十分有用。即自动帮忙给例子中的Menu类中定义了toString、Getter、Setter等方法。
通过上面的例子，大家可以发现，我们是使用@Data注解大大减少了代码量，使代码非常简洁。这也是很多开发者热衷于使用Lombok的主要原因。
另外，关于Lombok的使用，不同人有不同的看法，因为很多人都使用过Lombok，对于他的优点都比较了解，所以接下来我们重点说一下Lombok的使用会带来哪些问题。
Lombok有什么坏处？
强X队友
因为Lombok的使用要求开发者一定要在IDE中安装对应的插件。
如果未安装插件的话，使用IDE打开一个基于Lombok的项目的话会提示找不到方法等错误。导致项目编译失败。
也就是说，如果项目组中有一个人使用了Lombok，那么其他人就必须也要安装IDE插件。否则就没办法协同开发。
更重要的是，如果我们定义的一个jar包中使用了Lombok，那么就要求所有依赖这个jar包的所有应用都必须安装插件，这种侵入性是很高的。
代码可读性，可调试性低
在代码中使用了Lombok，确实可以帮忙减少很多代码，因为Lombok会帮忙自动生成很多代码。
但是这些代码是要在编译阶段才会生成的，所以在开发的过程中，其实很多代码其实是缺失的。
在代码中大量使用Lombok，就导致代码的可读性会低很多，而且也会给代码调试带来一定的问题。
比如，我们想要知道某个类中的某个属性的getter方法都被哪些类引用的话，就没那么简单了。
有坑
因为Lombok使代码开发非常简便，这就使得部分开发者对其产生过度依赖。
在使用Lombok过程中，如果对于各种注解的底层原理不理解的话，很容易产生意想不到的结果。
举一个简单的例子，我们知道，当我们使用@Data定义一个类的时候，会自动帮我们生成equals()方法 。
但是如果只使用了@Data，而不使用@EqualsAndHashCode(callSuper=true)的话，会默认是@EqualsAndHashCode(callSuper=false),这时候生成的equals()方法只会比较子类的属性，不会考虑从父类继承的属性，无论父类属性访问权限是否开放。
这就可能得到意想不到的结果
閱讀更多 陌塵編程遊戲解說教學 的文章
