公司的架构师要求把日志封装成 LogUtil 类,提供 sdk 给各团队使用,并且不允许使用 slf4j 直接打印日志,请问各位这么做有哪些好处(我还没想到任何好处)?

270 天前
 WillingXyz

所有的日志打印都通过 LogUtil 类,并且日志上还得加上 code 来区分,比如 LogUtil.info("code101", "xxx")。 不能直接使用 slf4j 的 log.info("xxx")。

我完全不能理解这种操作,和他讨论了很多次,我觉得这样没有任何好处,因为 slf4j 本来就是一个门面,并且 logback 等实现提供了 Filter ,Coverter ,Appender 等扩展,完全可以通过 logback 来实现扩展,而不是侵入业务代码,并且业务也很难都改成这种方式啊。

他说是为了统一入口,便于以后扩展。但给不出具体的例子。工作了十几年了,都没产生好处,还要坚持封装。

ps:此人是我 leader 的 leader 。

请问:封装成 LogUtil 是否真的有好处,且相比 logback 扩展实现的更好,只是我没有想到,欢迎各位指点

16519 次点击
所在节点    程序员
145 条回复
Bromine0x23
270 天前
MJTest
270 天前
线上出问题的时候动态修改 log level?
rockdodos
270 天前
脱裤子放屁
qdz
270 天前
好处是不用每个类定义 log 对象?没感觉有其他啥好处,新项目改就改了吧,旧项目让他自己改
yc8332
270 天前
这个就是统一日志格式吧。。做日志搜集的时候方便,不然如果每个人写一个格式怎么解析
lucasdev
270 天前
@unknown404 #26 如果是其他库或许可以这么说,但是 slf4j 出了 18 年了,在 mvnrepository 它是
#2 in MvnRepository
#1 in Logging Frameworks

Quartz 、Camel 、Akka 等有多少库使用了 slf4j

至于各种日志扩展,通过 Coverter 、Appender 等都可以实现,提供 sdk 引入即可,不需要侵入代码
kneo
270 天前
非要说好处就是可以强制调用者提供一个代码。非要说必要性那肯定是没有。可能这人岁数比较大,旧项目里代理的习惯。
daybreakfangyang
270 天前
不定规范,相当于在一坨💩山旁再拉一坨
bk201
270 天前
日志收集不是靠入侵业务代码实现的吧。我个人觉得日志用 util 类封装,然后放入业务代码里是很垃圾的做法。一方面要大批量改 log.info 代码,另外一方面后续接受的人并不会明白这个做法,增大代码 review 复杂度以及后续接收复杂度。po 主既然讨论了,能否把架构师的理由说出来听听。单纯统一入口,便于以后扩展不是理由,slf4j 已经足够抽象化。提出一个方案,必然是解决某个痛点,而不是过度设计
chendy
270 天前
从工作的角度,人家说啥就整啥就完事了
从经验的角度,我们也封了,但是总体来说 API 没啥变化,logger 看上去还是那个 logger 但是差了一些逻辑,直接出新 API 不是什么好文明
从自己的角度,应付过去就完事了,别耽误下班别耽误发工资就行
Mikukko
270 天前
个人感觉目前看是为了规范,保不齐后面就变成新的屎山
k9982874
270 天前
封装 LogUtil 很难理解吗?
封装 log 是统一格式,数据脱敏,数据清洗,大数据分析的第一步啊。
你只看你自己的业务,你们公司还有别的业务,其它语言写的平台吧,没有 slf4j 怎么办?
即使有 slf4j 开新项目每次都复制模板?模板分叉了怎么办?哪个模板是最新的?
天天制造屎山,还天天骂屎山
SmiteChow
270 天前
你不改怎么体现他的价值,他不给你提需求怎么体现你的价值?
securityCoding
270 天前
存粹是菜
cloudzhou
270 天前
没什么好处,并且代码很难看,统一入口不是这么个统一法
RandomJoke
270 天前
封装很常见,但是自己封装一个 Util 不常见,一般对日志有要求的,那么就基于 sl4j 做一个专门的 factory ,让业务无痛切换,底层实现格式化
neocanable
270 天前
bk201
270 天前
@k9982874 你说的这些其他日志框架都实现了,而且性能更好,完全没必要自己造轮子。数据脱敏,数据清洗,大数据分析也不靠入侵业务代码实现,Logstash 、Fluentd 。多语言、多平台靠使用统一的日志收集平台 ELK 。LogUtil 这种入侵业务代码的非业务代码才会造成屎山,让人摸不着头脑。
lucasdev
270 天前
@k9982874 1. slf4j 门面和 logback 等实现提供的扩展性都可以做到,楼主也说了,这些不是问题。
2. 每个语言有自己的最佳实践,别的语言或许封装一个 LogUtil 更为合适,但 Java 没必要。即使封装了 LogUtil ,也应该允许让其作为 slf4j 的实现,而不是不允许使用 slf4j 直接打印日志。此外,不同平台的日志不一定是统一管理。
3. 不存在模板复制的问题,安全、日志相关的自定义 sdk 使用 snapshot ,每次从 mvn repo 拉取最新版本。
wangyzj
270 天前
没啥毛病
理论上一些高阶功能无法走扩展,尤其是公司内部的一些基础设施集成
对于用户来说最简单的方法集成公司现有平台是最好的改造方向
想法是好的,但得把功能点先列出来
这种东西作为基础设施一环,想不清楚就是一坨,想清楚了整个公司数据一致性都会提高

你老板如果写不出来具体 feature 可以给方向
但感觉他也不太懂

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

https://ex.noerr.eu.org/t/1100354

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

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

© 2021 V2EX