Lombok 到底应不应该使用?
之前写了一篇《干啥呢,Lombok 》,读者反响还不错。
有一些批评的声音:使用 Lombok 等于强 X 了你的队友,他们也必须使用,否则代码就编译不通过。
但我自己的体验是,省去 getter/setter 似乎真的很省心。
V 站的朋友们,你们觉得呢?
----------------------- 以下是精选回复-----------------------
答:队友被强 X 了之后表示很开心
答:Lombok 不只有 get set,还有很多其他的实用功能。被强 X 的没坏处
答:省掉 get/set 并没有带来多大的好处
答:lombok 只是为了 get/set 不如引入 kotlin
答:难道你们只知道 lombok 这么片面的功能么?除了 get/set 就没别的了?麻烦看一下官方文档 OK ?
答:用 ide 自动生成也能应付大多数场景了,所以用不用看大家喜好吧,但是 lombok 还提供其它实用功能,比如 builder,要用 lombok 最好还是要知道生成的到底是些什么代码比较好
答:Kotlin 欢迎你
答:楼主贴下《干啥呢,Lombok 》呗
答:手指断了别怪我
答:正如 5 楼所说,Lombok 的功能不仅是 getter/setter。
团队开发中,用不用,怎么用,很多时候不是一个普通成员能决定的,如果要用,就算不服也得用。较为规模的项目一整套开发规范不是白写的。
平常站里没见几个写 Java 的,但是一旦碰到这种可以撕逼的问题,仿佛人均 Java 开发十年。
答:某 Spring 开发者:快看这有个超级好用的 lombok。( Spring 有些文档中已经只提供使用了 lombok 的代码示例)
某专职代码评审员:别给我添麻烦,用 lombok 的一律扣分。
——团队文化决定了是该不该用。
答:start.spring.io 输入 lombok 是有结果的...
答:用 Git 是不是 QJ 了喜欢用 SVN 的同学?
Java 后面更新也有吸收 Lombok 的特性。比如 var
答:我们规定了必须用 Lombok,因为吃过亏,有的 Bean 几十个属性,增加或者修改属性的时候不小心就会忘了修改 getter 或者 setter,导致前端提交的数据服务器端没有得到而产生 Bug,查找了很久发现原来是新增加的属性忘了增加 setter。
答:SpringBoot starter 的组件可选列表里面有 Lombok
答:当项目中不止 java 的时候就不该用了...比如混入了 groovy,不过大部分人吃不到这个亏..
仁者见仁智者见智吧,单纯自己玩的时候会用一下,但是团队合作会避免
答:这个应该是团队大佬决定的事情
答:lombok 我记得是有坑在里面的
答:新项目用到了 一开始不知道干啥的 但是装了插件以后用的真的狠爽
答:我觉得 Lombok 除了简化代码外, 暂时算是 Amber 正式发布前的替代品, 如果能使用 Lombok, 相信 Amber 这么大的福利立刻就会被团队所接受吧。
答:我认为那种在 facade 包里用 lombok 的才是 QJ
答:不用,用 kotlin
答:为什么队友必须用?就算用记事本也能编译通过
答:个人很反感用这种干预语法糖的插件。如果团队决定要用我建议换语言。反正 Java 慢慢要死掉的。
答:代码 少就是正义,少才错误少,要不 ts kotlin 也就不会这么火了
答:spring 本身并不喜欢使用 Lombok,这里有一个去掉 Lombok 的 issue: https://github.com/spring-projects/spring-session/issues/702
另外在某个 spring 的工程里,明确提到不喜欢用 Lombok,忘记在哪里了。
在 spring boot 工程里,可以找到一些支持 Lombok 的代码: https://github.com/spring-projects/spring-boot/search?q=Lombok&type=Code
Lombok 带来的负担要超出大部分人的想像。另外,并不是所有人都会用 IDE 的,强制别人用 IDE 才能正常打开你的代码,非常的不友好。
答:你能想到的功能 ide 代码生成 和 live template 都有解决方案
答:不存在应不应该,毕竟 lombok 没有强大到非用不可,也没有坑到没法用,所以大家肯定各执一词。所以:
1. 自己的项目,喜欢用就用,不喜欢用就不用
2. 团队的项目,大家决定用不用,或者老大决定用不用
没了
答:个人觉得 Lombok 不算侵入性很强的,开发还是能带来很大便利
答:这玩意有坑,但是好用。
不过想用其他 JVM 混编就不要用了,这玩意不是用的 APT ( Annotation Processing Tool ),而是 AST 无法通过简单的调整编译顺序让其他 JVM 语言找到 Lombok 生成的代码。
答:一直用着,在写内部类的时候舒服多了
答:一点微小的拙见
初探 Lombok 并拒绝它 https://blog.ahao.moe/posts/learn_Lombok_and_reject_it.html
拒绝被强 X,也不强 X 别人 (
答:Lombok 与 apt 的兼容性有待提高
答:用 lombok 一时爽,一直用一直爽。
答:lomok 本身就是 java 演进太慢的问题,希望能像前端的各种 slim 一样只是一种暂时的解决方案
答:用过一下。全组人必须得一起用。
lombok 最大的问题是需要结合 ide 插件使用,虽然 idea 配置不困难,不过组内一些年轻的“老同志”接受不了这风骚的操作。最后只好放弃了。
果断 kotlin。
答:自从有了 Kotlin ……
答:看 Spring,Spring 用我们就用
答:我很喜欢用,但确实强 X 了队友。
答:这东西,少数服从多数,不用也影响不大,用了也没啥坏处。反正我们是建议使用的。
答:知道但没用过 感觉并没有提高多少效率 反而容易造成分歧 比如没用过的人就不理解队友的代码了
答:Hail Kotlin!
data class MyDataClass(val age: Int, val name:String)
答:kotlin data class + 1
跟 Java 无缝兼容,idea 也自带支持,写爬虫很舒服
答:lombok 遇到过坑 版本太新会 require jdk9+
答:kotlin data class 了解一下
答:这时候就突然觉得,java 生态开始分裂了。
大家盯着 lombok 肉体强 X,而忽略了 kotlin、scala 这些携生态的方式对 java 的肉体和思想的双重羞辱嘛?
答:实际使用中,个人感觉 lombok 最麻烦的就是很难处理在 maven 项目中和 aspectj 共存的问题
答:现在 ide 能够自动生成 get/set 方法 我觉得没必要用
答:如果团队能协商使用的话,当然用了更好
主要是 lombok 不仅仅是 get / set 还有很多便捷的功能
答:我個人是很喜歡 lombok 的 至於強沒強 X 隊友 我並不關心
反正誰不想省事
答:lombok 在解决 Java 语言冗余方面做的很好,但是不够彻底。比较起来,我会倾向:
使用 Kotlin 或者混合使用 Kotlin 来解决语言层面冗余的问题。
lombok 目前实现也有一些 trick 和 hack,如果有更好的实现也许我会给 lombok 加分。另外 lombok 带来的一些隐性的成本是一般开发者用脚投票时不太容易看到的(毕竟短时间看省事儿好用了),团队决策者是需要考虑这些的。我个人的看法是,观望并等待更好的解决方案,或者等待 lombok 更加成熟一些再进行推广(但是现阶段我不会在团队中严格禁止)。
至于大家提到的 IDE 配置问题,我觉得完全不是一个问题和障碍,Java 目前已经是重度依赖 IDE 的语言了,这点儿配置成本如果都无法接受,听起来很滑稽。
答:如果新团队可以引入,既有项目的话,没太大必要,除了让你自己觉得这很爽只在,潜在收益不太大
答:其实就是 Java 没做好,lombok 擦了屁股而已。
那些拉了屎不擦屁股的,难道不难受吗?
答:所以我们都在摸鱼
答:无所谓,爱用不用,不用就去手写,屁大点事儿也要讨论半天。
答:基本上会用,但是要注意其中的一些坑,别让团队踩上了
0条评论