Javaer,项目中会引入多个同类型的依赖吗?

2022-02-15 11:09:11 +08:00
 Breadykid

问题

工作依赖,经常遇到项目中有重复依赖的引入,比如:

好混乱啊,在组件的选型上不应该整个小组讨论或者架构师拍板嘛?!

1788 次点击
所在节点    程序员
14 条回复
tedzhou1221
2022-02-15 11:42:54 +08:00
需要的是公司内部的开发规范和代码审查。规定到底使用什么组件,然后有人去监督
leeyuzhe
2022-02-15 13:25:45 +08:00
理论上是的,但是我发现我们公司的项目 fasterjson gson jackson
feitxue
2022-02-15 13:57:47 +08:00
其实代码能跑就行.
之前记得写的代码里本身没用到 guava 的
但是引用的 swagger 是依赖 guava 的.
升级 swagger 还遇到了 guava 的冲突.
所以.没必要的情况,别管相同功能的依赖重复.
chendy
2022-02-15 14:03:49 +08:00
guava vs hutool ,印象里后者是个大而全的工具包,前者很多依赖本身会依赖,所以无所谓
fastjson vs gson ,引多了其实也无所谓
mockito vs powermock ,前者一般够用,后者特殊需求
jedis vs resttemplate ,后者依赖前者(也不一定,现在好像换了默认实现了),一些底层操作直接走 jedis 应该更方便
好了不洗了,说白了只要依赖之间不冲突,爱用啥用啥,项目内甚至模块内统一就行,都是小事
Breadykid
2022-02-15 14:39:21 +08:00
@leeyuzhe 三个都用了吗?
@feitxue 那 swagger 里面会带挂而不是单独引入
@chendy 过多的依赖增大 jar 包体积
chendy
2022-02-15 14:41:19 +08:00
@Breadykid 你说的这几个 jar 包好像都没有 es 客户端大(捂脸),在意的话尝试做一下分层就行
xiqishow
2022-02-15 17:05:13 +08:00
即使自己的项目能统一管理好外部库,也没办法完全控制第三方库的引用,感觉最好的办法是控制自己工程内的相同功能的标准实现,做到无论是谁开发都使用一套标准工具就好
zhady009
2022-02-15 17:17:04 +08:00
我的经验
核心库用 spring 的工具类 guava apache-commons 系列差不多了
json 库用 jackson 因为 spring mvc 里依赖了没必要引入更多的包
redis 用 redisson 最好用的客户端了用过都知道
ut 用 mockito 就好 spring-test 里依赖了
boris93
2022-02-15 18:17:19 +08:00
你们需要规范+1
这情况看起来就是,我需要个功能,但是我不管是不是已经引入了类似的包,我只管加上我知道的那个包
EscYezi
2022-02-15 22:37:27 +08:00
idea 输入 StringU ,会提示一堆 StringUtil
所以我就直接用 hutool 的 StrUtil 了🐶
Breadykid
2022-02-16 13:15:12 +08:00
@EscYezi 每次同功能同类名不同包就很反感
@boris93 就是那么的不规范
@zhady009 我提出了疑问,领导说不动- -
@chendy 怎么分层鸭?
EscYezi
2022-02-16 13:25:54 +08:00
@Breadykid #11 有点难控制,比如 mytatis-plus 自带 StringUtil spring 自带 公司项目引进来 apache-common ,还有其他三方库……
和#7 一个观点,项目里都用一套就行了
fanxasy
2022-02-17 13:50:49 +08:00
你可以翻翻你依赖里的子依赖,你就会发现这事没法解决
kid1412621
2023-11-15 16:49:37 +08:00
不应该是 jedis vs redisson 吗😅

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/833934

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX