我要狠狠的反驳“公司禁止使用Lombok”的观点

经常在其它各个地方在说公司禁止使用Lombok , 我一直不明白为什么不让用 , 今天看到一篇文章列举了一下“缺点” , 这里我只想狠狠地反驳 , 看到列举的理由我竟无言以对 。
我要狠狠的反驳“公司禁止使用Lombok”的观点文章插图
原文如下:下面 , 结合我自己使用 Lombok 之后的感受 , 谈谈 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是一个非常简单的知识点 , 十分钟就能上手使用 , 你却抱怨要花费时间学习 , 作为程序员不是无时无刻都在学习吗 , 你有这种抱怨只能你放弃程序员这个工作吧!
我要狠狠的反驳“公司禁止使用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”的观点文章插图


推荐阅读