今天小編就為大家總結了下各方發言，你更偏向誰呢？
推薦使用的網友這樣說：
1、市場有需求就會流行，普惠性比較高，只要能提高生產力（節約開發成本，創造價值）的工具都是好工具。如果幾年后這個需求還在，還會有“Lombok完善版”出現。
2、有人覺得作為現如今大部分的開發人員，在開發中面對的是如何快速的開發，而不是去想是否會破壞源碼的可讀性和完整性；所以推薦使用。
3、就像數碼寶貝進化似的，一開始進化的畫面很是詳細，到了后面因時間問題進化畫面不再是那么必要的后，閃個光就進化了，剛學java的確實不適合用，但是考慮到開發進度，還是很有必要去用的。
4、能說出“省去了手動創建getter/setter方法的麻煩，但大大降低了源代碼的可讀性和完整性，降低了閱讀源代碼的舒適度；看似沒有多么重要的小改動，反而是為了表面簡潔而簡潔。”這句話的人我感覺你不適合干開發！
5、代碼的功能是為了實現更多的功能，如果花時間去寫getter/setter，也不是程序開發者想要的，目的就是花最少的時間，實現最有價值的功能。
6、用了Lombok省了不少事，而且也不會給性能帶來那么重的負擔，手寫getter/setter 早晚會因為手誤出bug，一個女孩會因為戴項鏈而被壓死嗎，明顯不會，一個團隊一起做開發，統一用一個插件還統一不起來？真搞不懂不推薦的人的理由在哪里。
7、非常贊同使用，人都不斷的在進化，機器也是一樣，更何況一幫程序員呢，一些簡單無意義的操作。為啥要重復再重復？難道不應該留點精力去做其他的事情么？
8、我是一個極其討厭冗長代碼的人，真的看過去腦殼痛，也有強迫癥。所以必須使用Lombok，如果真有特殊字段需要查看，可以單獨寫這個字段的get,set.大部分字段都跟咸魚一般，沒什么卵用。but，在公司內網開發，插件都下不了，所以公司開發還是生成的get,set。
?不推薦使用的網友這樣說：
1、雖然省去了手動創建getter/setter方法的麻煩，但大大降低了源代碼的可讀性和完整性，降低了閱讀源代碼的舒適度；看似沒有多么重要的小改動，其實反而是為了表面簡潔而簡潔。
2、實體類所有的內容還是字節構建的好，雖然可以使框架的用注解來代替一部分內容，可一旦實體類中出現其他問題，就很難查找到問題，而且此框架省略的代碼，也可以使用工具自動生成，生成后，我們也可以自行更改內容，而不局限于注解動態生成的。
3、為了簡潔而簡潔。而且現在的各種IDE自動生成代碼功能都很強大，并沒有節省多少事。最重要的是：只要有一個用這種東西，全組都被迫使用。
4、脅迫使用！當你的源代碼中使用了Lombok，恰好你的代碼又被其他的人所使用，那么依賴你代碼的人，也必須安裝Lombok插件(不管他們喜不喜歡)，同時還要花費時間去了解Lombok注解的使用情況，如果不那么做，代碼將無法正常運行。使用過Lombok之后，我發現這是一種很流氓的行為。
5、存在即合理從來都是一個錯誤的言論。黑格爾的愿意是存在是有原因的。而Lombok的存在固然是有原因的，但是不使用的理由也是相當充分的。因此，還是看開發團隊的代碼規范吧。
6、索然省去了生成setter/getter，構造方法和toString的麻煩，但代碼可讀性降低；另當字段過多時，生成的含參構造方法的順序不確定；代碼運行需要配置相關插件。
7、不推薦，在有些代碼不規范的項目里，如駝峰命名不規范，可能會導致一些未知問題，已在實際項目中遇到過兩次這種不清楚的問題，最后都是修改了get和set方法得到了解決。
8、眾所周知，java早期風靡的原因不是代碼優美、程序員能偷懶，而是程序員能夠花費非常小的代價就能協同工作、項目能夠靈活的部署和可控的代碼管理。再看Lombok。。。很不java。。。再說，那些用Lombok的同事，你們用Lombok可以，但是用完后，找個工具把缺少的代碼補回來再提交代碼會X嘛。。。點一點，不比你們每個類加個標簽要慢。
