內聯腳本被視為是有害的

這篇博客文章解釋了從我參與的項目之一中刪除Lombok項目的動機。 它反映了我的個人觀點，并不妨礙特定的技術。

大約三年前，我認識了Project Lombok ，這是一個添加Java代碼的庫。 我從一開始就喜歡它，因為它貢獻了很多有用的功能。 我經常處理實體（數據類）和值對象，因此@Data或Kotlins data class非常方便也就不足為奇了。 從字面上看，您會得到更多的回報。
我在這里提到Kotlin是因為它共享了我們從Lombok獲得的一些屬性。

通常在代碼庫中開始采用這樣的（語言生成）功能。 代碼發展得越多，使用這些功能的組件就越多，因為使用免費獲得的功能*方便并且已經習慣了。 使用單個注釋或單個關鍵字，我們選擇了可以為我們提供屬性訪問器的東西，包括equals / hashCode ， toString ，生成的構造函數等。

* ：實際上， 沒有免費的午餐之類的東西 。

現在，有人可以說，只使用您需要的東西，而您完全正確。 如果只需要屬性訪問器，請使用@Getters和@Setters 。 如果希望獲得equals / hashCode ，則添加適當的注釋。 真正。 在許多情況下，我們認為我們需要更多的功能，因此為什么當使用單個@Data注釋獲得我們想要的（以及更多）內容時，為什么要將具有多個注釋的代碼弄亂了。 這不是樣板嗎？ 因此，減少注釋的數量似乎是一件好事。

好：不。

原因如下：

偶然的復雜性

通過引入代碼生成（這就是Lombok和Kotlin data classes所做的事情），我們獲得了很多功能，但是真正的問題應該是：我是否希望使用該功能？ 還是我們想對功能進行顯式控制？
在某些情況下，出于方便考慮，我們使用了數據類。 隨著Lombok的刪除，我們發現我們隱式使用了免費獲得的許多功能* ，例如相等性檢查。 隨著生成代碼的刪除，許多測試開始失敗，因為這些功能不再可用。 缺少的功能提出了一個問題：是否需要此功能？

只需選擇數據類，就可以很容易地忽略這個問題。 與此相反，采用一種明確的方法，我們將花費更多的時間討論該主題。 可能我們的測試看起來有所不同，或者我們會更明確地了解特定功能。

在沒有生成實用程序的情況下顯式控制代碼會迫使您考慮該功能是否真正需要。

（重復）PSA：“代碼生成，這樣您就可以更快地做錯事……” #GeeCon

— Oliver Drotbohm🥁＆👨?💻（@odrotbohm） 2014年10月23日

什么是樣板？

樣板代碼是我們反復需要編寫以公開某些功能的代碼，而不是告訴代碼我們希望此功能開箱即用。 典型的示例是屬性訪問器（Getters，Setters）和相等性檢查（ equals / hashCode ）。 有時也是構造函數。
與我們以前的想法相反，將Lombok注釋分解為自己的組件并不是樣板。 它不精確，方便且不負責任。

在編譯器周圍工作

這是Lombok特定的方面。 Java編譯器從未打算用于Lombok要做的事情。 Lombok的維護者為實現Lombok所做的事情做了出色的工作。 這是以針對特定編譯器的編譯器中幾種解決方法的代價為代價的。 javac所需的內容在某種程度上與Eclipse的ecj需要執行的操作不同。

在靜態布局中，JDK和Eclipse IDE永不改變，一切都很好。 但是，現實世界是不同的。 Eclipse發布了更新程序，從Java 9開始，Java發布節奏加快了。Lombok項目不是由公司驅動的，而是由時間有限的開源貢獻者團隊驅動的。

過去，Java升級導致Lombok成為阻止我們升級到較新Java版本的組件：編譯器內部發生了變化，Lombok尚無機會追趕。 隨著Lombok用法遍及整個代碼庫，唯一的選擇就是不升級。

但是：從長遠來看，不升級不是一種選擇。
最終，Lombok趕上了路，為再次升級到新版本開辟了道路。

插入所有東西！

Lombok的一個方面是它需要告訴您的IDE有關生成的類成員的信息。 盡管您的代碼中沒有例如Setter，但在編譯后的代碼中卻有，所以您的IDE需要知道這一點，以免出現錯誤。 對于IntelliJ和Netbeans而言，這并不是什么大問題，因為您可以啟用注釋處理并使用可選的IntelliJ插件。 對于Eclipse，您需要一個可修改Eclipse行為的代理。 如果沒有正確的IDE設置，那么任何想要處理代碼的人都會收到錯誤/警告，并提出以下問題：那怎么辦？

認知負荷

從某種意義上說，每種非顯而易見的行為都會導致復雜性。 同樣，每個非默認行為都導致相同的路徑。 初次使用這種代碼庫的人們需要了解如何掌握該代碼庫。 盡管這不是Lombok特有的，但所有為代碼提供附加功能的輔助實用程序（代碼生成器，AOP，JVM代理，一般來說字節碼操作）都具有被描述為魔術的潛力。 為什么是魔法？ 因為一開始發生的情況并不明顯。 一旦有人向您解釋了竅門，這種情況就可能變得顯而易見。

其他人更改您的（已編譯）代碼

使用代碼生成功能，我們可以依靠其他人來完成正確的工作。 我們會購買它們，因此他們的工具為我們提供了對我們有用的功能。 我們不再需要為equals / hashCode正確的實現而煩惱，添加屬性變得不費吹灰之力，因為這一代人為我們代勞。 手動擴展equals / hashCode并非易事。 某些工具可以為我們做到這一點，但是正如您可能已經預料到的，我們在不大幅改善我們狀況的情況下將tool2 tool1 tool2 。
有時，工具會更改其生成代碼的方式或生成的位以及停止生成的位。 找出這些變化并不是一件有趣的事情，但是如果我們已經購買了他們的編程模型，那么我們就別無選擇。 唯一的選擇是退后，這是以手動實施為代價的。

偶然的復雜性2：構建

根據上下文，這可能僅與我們的項目有關。 我們附帶了帶有公共API表面的庫，并附帶了源jar和Javadoc。 默認情況下，Lombok僅適用于您的.class文件。 這將導致源jar不包含生成的方法，并且Javadoc也不列出生成的成員。 從消除樣板代碼開始，隨著構建復雜性的提高而繼續。 為了獲得正確的源jar和Javadoc，我們需要向構建中添加插件，該插件首先要對代碼進行delombok，并允許源jar / Javadoc在delomboked源之上運行。

根據您的設置，使用delomboked的源僅用于源jar和Javadoc。 這意味著您將一個版本的代碼用于文檔目的。 該代碼與您用于編譯的代碼不同。 Lombok本質上導致相同的輸出代碼。 使這一方面變得明顯會使我們感到難受。

復雜性的增加通常會花費更長的構建時間，我們可能會問自己，這是否值得我們得到。

一個好的開發者就像一個狼人：害怕銀彈。

—🖖JochenMader🇪🇺（@codepitbull） 2016年10月8日

Lombok正在分化社區

即使前面的部分聽起來好像我們正在處理嚴重的問題，但其中許多可能是特定于我們的項目上下文的。 Lombok承諾減少樣板代碼。 它做得很好。 在面向數據的環境中工作，在該環境中我們需要各種對象對象進行測試甚至在生產代碼中，都需要大量的代碼才能使用適當的數據對象/值對象。
為hashCode提供良好的實現并hashCode 。 由于不正確的hashCode實現，有兩個CVE。 忘記在equals / hashCode添加字段是錯誤的另一個常見來源。
使用代碼生成時，我們消除了這些錯誤源。 此外，不存在的代碼也不會影響我們的測試覆蓋率統計信息。 這并不意味著它不需要測試。

查看Lombok刪除提交的統計信息，我們看到：

刪除：300行
新增：1200線

這很好地說明了我們從使用Lombok中獲得的好處。 一旦在一個地方使用了Lombok，我們通常會在其他地方繼續使用它-因為它已經在類路徑中了。 查看已刪除的300行，我們應該改為將它們刪除為150行，因為它通常是一個import語句和一個注釋，使我們在便捷代碼和手動維護代碼之間的比例大致為1：8。

我們不需要支付任何代碼行，但是擁有更多代碼會帶來更大的維護面。

看看我的推文 ，有非常相反的意見。 這些React就是為什么在您應該/不應該使用Project Lombok或Kotlin數據類時沒有唯一答案的原因，因為它始終取決于您的團隊，上下文和所編寫的代碼類型。

我最近從項目中刪除了@project_lombok 。 一條推文太短，無法總結結果。 將跟進一篇博客文章。 https://t.co/wpS33nKScA

-Mark Paluch 👨?💻＆🎹（@ mp911de） 2019年7月2日

雙重痛苦

不使用代碼生成功能會使代碼明確。 顯式代碼始終可以揭示其作用。 顯式代碼需要設計。 由于立即得到的結果和最初的簡單性，進入代碼生成功能很誘人。 一旦使用了這些功能，我們就會經歷不同的情況，并了解并非立即顯而易見的方面。 由于相關的成本，很難消除一個非常有益的功能。 還記得1：8的LoC比率嗎？

僅僅因為我們想擺脫代碼生成，并不意味著我們可以免費刪除該工具收到的功能* 。 而是意味著我們需要自行提供此功能。

我這樣說：您有一所房子，將其出租給某些租戶，因為租用房屋可以賺錢。 最終，您發現租戶很亂，并且開始擺脫租戶。 租戶出門后，您便會意識到混亂的程度，并開始清理房屋，以免房屋松動。

最終結果是相同的：您為該學習付出了很多努力（可能還有金錢）。

如果您的租戶行為正常，則沒有理由改變現狀。

翻譯自: https://www.javacodegeeks.com/2019/07/data-classes-considered-harmful.html

內聯腳本被視為是有害的

總結

以上是生活随笔為你收集整理的内联脚本被视为是有害的_数据类被认为有害的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。