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

[WillingXyz]

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

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

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

ps：此人是我 leader 的 leader 。

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

[night98]

@dcsuibian #139 一般能提出这种问题的企业，没啥性能要求

[z1829909]

@CodeCodeStudy 直接通过关键字搜索不是更快吗, 为什么还需要再转一层呢.

[sampeng]

为啥都在说统一封装的好处呢，都不看原文到底？ op 说的很清楚了，已经做了 sdk 的封装。这就已经 ok 了啊…是嫌弃架构师，脱裤子放屁…多此一举。有且不可能在成熟项目里面更换日志底层。这个未来的变更可能把公司干黄了都不会有可能性。就算你封装了一层，你随便换一个试试…而且都是版本绑定，谁换 sdk 全部服务产品线自动升级啊，感觉架构师是个水货。

[oneisall8955]

slfj 本身就提供很好的扩展性，没必要，集成 starter+Lombok 自动注入直接用就好了

[jeesk]

公司内部以前分享的内容

1. 对内较真，对外果断
2. 快速犯 2 次错误并修正问题， 比陷入设计质量更能够提交设计能力。
3. 跳出争论， 先想一想自己坚持的方案和其他的方案的差异是否在实际情况中带来的真实影响到底有多大。 如果区别不搭， 先想办法让事情可以走下去，只有走下去最终产出结果，此刻争论，纠结的对错才会被赋予微不足道的意义。


再想想 go-format ， 在看看 java 和 kotlin 的各种风格。


最后我就要搬出瑞达利欧的一段：

一个决策团队，如果内部有人因为决策没有达到自己的需求而持续闹事，肯定要遭遇败绩——在公司、机构，甚至政治体系和国家，这样的例子比比皆是。我不是说人们要假装喜欢相关决策，或者不再对相关问题进行核查。我的意思是，为了提高有效性，所有集体合作的团队必须遵照规定，为分歧解决预留时间，同时，要让持不同意见的少数派明白，一旦他们的观点被推翻，整个团队的一致性要优先于个人的喜好。

团队比个人更重要，要避免破坏既定路径的行为。 换位思考很重要，决策是由公司管理层决定的， 如果你是管理层？