CTO 說禁用 Lombok

經常在其他各個地方在說公司禁止使用 Lombok，我一直不明白為什麼不讓用，看到一篇文章列舉了一些“缺點”，這裡我隻想狠狠地反駁，看到列舉的理由我竟無言以對。

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

01、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 肯定會支援更高的版本，那時相容問題将不存在。

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 很多配套東西在企業中使用還不成熟吧。