[[392340]]
圖片來自 Pexels 

原文如下：下面，結合我自己使用 Lombok 之后的感受，談談 Lombok 帶來的幾大痛點。

01JDK 版本問題

當我想要將現有項目的 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 肯定會支持更高的版本，那時兼容問題將不存在。

02脅迫使用

當你的源代碼中使用了 Lombok，恰好你的代碼又被其他的人所使用，那么依賴你代碼的人，也必須安裝 Lombok 插件 (不管他們喜不喜歡)。

同時還要花費時間去了解 Lombok 注解的使用情況，如果不那么做，代碼將無法正常運行。使用過 Lombok 之后，我發現這是一種很流氓的行為。

我的反駁：你裝不裝 Lombok 插件不是你喜不喜歡，不是由你個人意愿決定的，這是工作，公司要求怎么做就要怎么做，這是規定。

Lombok 是一個非常簡單的知識點，十分鐘就能上手使用，你卻抱怨要花費時間學習，作為程序員不是無時無刻都在學習嗎，你有這種抱怨只能你放棄程序員這個工作吧!

03可讀性差

Lombok 隱藏了 JavaBean 封裝的細節，如果你使用 @AllArgsConstructor 注解，它將提供一個巨型構造器，讓外界有機會在初始化對象時修改類中所有的屬性。

首先，這是極其不安全的，因為類中某系屬性我們是不希望被修改的。

另外，如果某個類中有幾十個屬性存在，就會有一個包含幾十個參數的構造器被 Lombok 注入到類中，這是不理智的行為。

其次，構造器參數的順序完全由 Lombok 所以制，我們并不能操控，只有當你需要調試時才發現有一個奇怪的 “小強” 在等著你。

最后，在運行代碼之前，所有 JavaBean 中的方法你只能想象他們長什么樣子，你并不能看見。

我的反駁：不滿意 @AllArgsConstructor 的做法你可以使用 @Builder 啊，這個支持你任意順序任意數量的創建對象，你不了解 Lombok 的其他用法就說它不好。

你要看 JavaBean 中的方法?它有啥好看的，Getter 和 Setter 方法有啥好看的，你不知道 Getter 和 Setter 方法長什么樣嗎?實在不明白有什么好看的?

04代碼耦合度增加

當你使用 Lombok 來編寫某一個模塊的代碼后，其余依賴此模塊的其他代碼都需要引入 Lombok 依賴，同時還需要在 IDE 中安裝 Lombok 的插件。

雖然 Lombok 的依賴包并不大，但就因為其中一個地方使用了 Lombok，其余所有的依賴方都要強制加入 Lombok 的 Jar 包，這是一種入侵式的耦合，如果再遇上 JDK 版本問題，這將是一場災難。

我的反駁：我們在使用其他框架時，那框架引入了不計其數的包，現在要引入一個很小的包都在斤斤計較，Lombok 這么好用，幾乎所有項目都會使用到，這還需要強制引入嗎，我們自覺的都會在 maven 的 parent 依賴中統一引入了。

05得不償失

使用 Lombok，一時覺得很爽，但它卻污染了你的代碼，破壞了 Java 代碼的完整性，可讀性和安全性，同時還增加的團隊的技術債務，這是一種弊大于利，得不償失的操作。

如果你確實想讓自己的代碼更加精煉，同時又兼顧可讀性和編碼效率，不妨使用主流的 Scala 或 Kotlin 這一基于 JVM 的語言。

我的反駁：破壞了完整性?加上臃腫的 Getter&Setter 你卻嫌棄臃腫，不加你又說破壞代碼的完整性，你想怎么做。增加團隊的技術債務?學個 Lombok 十分鐘的事情，有什么好增加的。

要使用 Kotlin?一般公司都沒有這么激進吧，現在 Kotlin 很多配套東西在企業中使用還不成熟吧。

作者：Java 實用技術

編輯：陶家龍

出處：toutiao.com/i6884399145390440964