CTO 說禁用 Lombok,看我懟死他!

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

圖片來自 Pexels

01

JDK 版本問題

於是我不得不將所有的 Lombok 註解從項目源代碼中清除,並使用 IDE 自帶的功能生成 getter/setter,equals,hashCode,toString 以及構造器等方法,你也可以使用 Delombok 工具完成這一過程。但這終究會消耗你很多的時間。

**我的反駁:**很多公司一旦確定 JDK 版本在很長的時間都不會改變(比如銀行項目很多都在用 JDK1.6,你問他願意升級到 JDK11 不?),現在都出到 14 版本了,你看有多少公司會升級!

**我的反駁:**你裝不裝 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

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/NhP0kUMI39fdXVK0ydC4Jg