新来的老大说,“公司以后禁止使用Lombok”,我表示反对~

372 阅读4分钟

经常在其它各个地方在说公司禁止使用Lombok,我一直不明白为什么不让用,今天看到一篇文章列举了一下“缺点”,这里我只想狠狠地反驳,看到列举的理由我竟无言以对。

JDK 版本问题

当我想要将现有项目的 JDK 从 Java 8 升级到 Java 11 时,我发现 Lombok 不能正常工作了。于是我不得不将所有的 Lombok 注解从项目源代码中清除,并使用 IDE 自带的功能生成 getter/setter,equals,hashCode,toString 以及构造器等方法,你也可以使用 Delombok 工具完成这一过程。但这终究会消耗你很多的时间。

我的反驳:很多公司一旦确定JDK版本在很长的时间都不会改变(比如银行项目很多都在用jdk1.6,你问他愿意升级到jdk11不?),现在都出到14版本了,你看有多少公司会升级!如现在很多公司都在用JDK1.8,任你出到JDK14,我依然继续使用JDK1.8,等你出到JDK20时我相信Lombok肯定会支持更高的版本,那时兼容问题将不存在。

胁迫使用

当你的源代码中使用了 Lombok,恰好你的代码又被其他的人所使用,那么依赖你代码的人,也必须安装 Lombok 插件 (不管他们喜不喜欢),同时还要花费时间去了解 Lombok 注解的使用情况,如果不那么做,代码将无法正常运行。使用过 Lombok 之后,我发现这是一种很流氓的行为。

我的反驳:你装不装Lombok 插件不是你喜不喜欢,不是由你个人意愿决定的,这是工作,公司要求怎么做就要怎么做,这是规定。Lombok是一个非常简单的知识点,十分钟就能上手使用,你却抱怨要花费时间学习,作为程序员不是无时无刻都在学习吗,你有这种抱怨只能你放弃程序员这个工作吧!
在这里插入图片描述

可读性差

Lombok 隐藏了 JavaBean 封装的细节,如果你使用 @AllArgsConstructor 注解,它将提供一个巨型构造器,让外界有机会在初始化对象时修改类中所有的属性。

首先,这是极其不安全的,因为类中某系属性我们是不希望被修改的;

另外,如果某个类中有几十个属性存在,就会有一个包含几十个参数的构造器被 Lombok 注入到类中,这是不理智的行为;

其次,构造器参数的顺序完全由 Lombok 所以制,我们并不能操控,只有当你需要调试时才发现有一个奇怪的 “小强” 在等着你;

最后,在运行代码之前,所有 JavaBean 中的方法你只能想象他们长什么样子,你并不能看见。

我的反驳:不满意@AllArgsConstructor的做法你可以使用@Builder啊,这个支持你任意顺序任意数量的创建对象,你不了解Lombok的其它用法就说它不好。你要看JavaBean中的方法?它有啥好看的,Getter和Setter方法有啥好看的,你不知道Getter和Setter方法长什么样吗?实在不明白有什么好看的?

代码耦合度增加

当你使用 Lombok 来编写某一个模块的代码后,其余依赖此模块的其他代码都需要引入 Lombok 依赖,同时还需要在 IDE 中安装 Lombok 的插件。

虽然 Lombok 的依赖包并不大,但就因为其中一个地方使用了 Lombok,其余所有的依赖方都要强制加入 Lombok 的 Jar 包,这是一种入侵式的耦合,如果再遇上 JDK 版本问题,这将是一场灾难。
在这里插入图片描述
我的反驳:我们在使用其它框架时,那框架引入了不计其数的包,现在要引入一个很小的包都在斤斤计较,Lombok这么好用,几乎所有项目都会使用到,这还需要强制引入吗,我们自觉的都会在maven的parent依赖中统一引入了。

得不偿失

使用 Lombok,一时觉得很爽,但它却污染了你的代码,破坏了 Java 代码的完整性,可读性和安全性,同时还增加的团队的技术债务,这是一种弊大于利,得不偿失的操作。如果你确实想让自己的代码更加精炼,同时又兼顾可读性和编码效率,不妨使用主流的 Scala 或 Kotlin 这一基于 JVM 的语言。

我的反驳:破坏了完整性?加上臃肿的Getter&Setter你却嫌弃臃肿,不加你又说破坏代码的完整性,你想怎么做。增加团队的技术债务?学个Lombok十分钟的事情,有什么好增加的。要使用Kotlin? 一般公司都没有这么激进吧,现在Kotlin很多配套东西在企业中使用还不成熟吧。

大家还有什么不同观点可以互相讨论。

作者:Java实用技术
来源:toutiao.com/i6884399145390440964