Lombok插件扭曲的审美，得不偿失！劝大家放弃使用lombok插件

为什么很多公司禁止使用Lombok？首先说使用Lombok有哪些隐患：

• JDK版本问题
• 胁迫使用
• 可读性差
• 代码耦合度增加
• 得不偿失

不得不承认，Lombok是一个很不错的java库，可以在编程时少些代码并耍耍酷，简单的几个注解可以干掉一大片模板代码。但是所有的源代码很多时候是用来阅读的，只有很少时间用来执行。

在没有用Lombok之前，我们的源代码看起来是这样的：

public class User {
    String data;
    String name;
    public User(String data,String name ){
        this.data=data;
        this.name=name;
    }
    public String getData() {
        return data;
    }

    public void setData(String data) {
        this.data = data;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "User{" +
                "data='" + data + '\'' +
                ", name='" + name + '\'' +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User)) return false;
        User user = (User) o;
        return Objects.equals(getData(), user.getData()) &&
                Objects.equals(getName(), user.getName());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getData(), getName());
    }
}

每一个JavaBean都充斥着getter、setter，equals，hashcode和toString。看起来非常的臃肿。尤其是不断地重复生成会浪费掉“没必要”的时间。
但是当我们使用Lombok插件后，IDEA便可以识别其“炫酷”的注解，使用Lombok的@getter，@setter注解后，代码变成了以下苗条的模样:

@Getter
@Setter
public class User {
    String data;
    String name;
    public User(String data,String name ){
        this.data=data;
        this.name=name;
    }
    
    @Override
    public String toString() {
        return "User{" +
                "data='" + data + '\'' +
                ", name='" + name + '\'' +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User)) return false;
        User user = (User) o;
        return Objects.equals(getData(), user.getData()) &&
                Objects.equals(getName(), user.getName());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getData(), getName());
    }
}

你以为Lombok就这点能耐？它能够让你的代码更“苗条”，用@EqualsAndHashCode注解替换到equals和hashcode方法，用@ToString注解干掉toString方法：

@Getter
@Setter
@EqualsAndHashCode
@ToString
public class User {
    String data;
    String name;
    public User(String data,String name ){
        this.data=data;
        this.name=name;
    }
}

相比一开始的代码是不是很炫酷，很苗条，很性感？你以为到此为止了？不止于此，你会发现类名上一大坨注解看起来很别扭，Lombok提供了一个组合注解@Data，可以替换类名头上“一坨”注解：

@Data
public class User {
    String data;
    String name;
    public User(String data,String name ){
        this.data=data;
        this.name=name;
    }
}

现在是否变成了你心中最完美的样子？除了这些，Lombok还有其他一些注解，例如@Slf4j，@NoArgsConstructor等等。
以上代码行数的变化也许是无数人喜欢Lombok的主要原因吧，但是Lombok在用的爽的同时，也为代码埋下了祸根！
使用Lombok插件之后，我们的代码处于亚健康状态，本质上讲，我们都在追求减少程序中的样板代码，以使其更精炼简洁，从而提高了代码的可读性和可维护性。但实际上Lombok并没有达到我们的愿景，它仅仅是利用java语言在编译时的空档期，使用很取巧的方式，将我们所需要的方法注入到当前类中。这种把戏并不智能和安全，反而会破坏java代码现有特性以及代码可读性。下面我们结合几个场景，谈谈Lombok带来的几大痛点：
1.JDK版本问题：
当把现有项目的JDK从Java8升级到Java11时，会发现Lombok不能正常工作了，这时你不得不将所有的Lombok注解从项目源码删除，并使用IDEA自带的功能生成getter、setter、equals、hashcode、toString以及构造器等方法，这最终不但没有节省时间，反而消耗了更多的时间和心情。
2.胁迫使用
当你的代码中使用了Lombok，恰好你的代码又被其他人使用，那么依赖你代码的人，也必须安装Lombok插件（无论别人喜不喜欢），同时还要花费时间去了解Lombok注解的使用情况，否则代码无法正常运行，因此这是很流氓的行为。（本人第一次解除Lombok就是用到其他人创建的实体类，发现没有getter和setter，但是发现了类上的注解，于是开启用上了Lombok）。
3.可读性差
Lombok隐藏了JavaBean的封装细节，如果使用了@AllArgsConstructor注解，它将提供一个巨型构造器，让外界有机会在初始化对象是修改类中所有的属性。首先这是极其不安全的。另外，如果类中有几十个属性，就会有一个包含几十个参数的构造器被Lombok注入到类中，这是不理智的。最后，在运行代码之前所有JavaBean中的方法你只能想象他们长什么样子，并不能看见。
4.代码耦合度增加
当你使用Lombok编写某一个模块后，其余依赖此模块的其他代码都需要引入Lombok的依赖，同时还需要再IDEA中安装Lombok的插件。虽然依赖包并不大，但是就因为一个地方用了Lombok，其余所有地方都要强制假如Lombok的jar包，这是一种入侵式的耦合，如果再遇上JDK版本问题，结果可想而知，这将是一场灾难。
5.得不偿失
使用Lombok，一时觉得很爽，但它却污染了你的代码，破坏了java代码的完整性，可读性和安全性，同时增加了团队的技术债务，这是一种弊大于利，得不偿失的操作。

---

总结

Lombok本身是一个优秀的Java代码库，为Java代码的简化提供了以中方式，但在使用此代码库时，需要了解到Lombok并非一个标准的Java库。除了上述的问题，可能还存在一些未知的风险。如果你正在参与一个团队项目或者大型项目，考虑到后续的升级和扩展，是否使用Lombok，请与你的团队多沟通和三思。
如果你自己没有跟团队沟通私自使用了，我只能说：年轻人，耗子尾汁。

本文参考微信公众号:java技术前线，有部分改动