日志瘦身方法论,我们真的不需要吗?

tree1年前 ⋅ 686 阅读

https://developer.aliyun.com/article/984058

工作中经常看到同事不打日志,线上出问题,就线下idea里面debug去找问题的原因。

再要么就是打很多日志,一点点逻辑就打日志,这样的人也是碰到过不少的,导致线上服务跑出来的日志直接占满了磁盘,隔几天就要清理磁盘一次。一时忘记清理,线上磁盘居然满了,导致生产服务不可用。。

日志事小,影响却很大,生产线上无小事。

这么简单的日志瘦身方法论,我在想 我们就真的不需要吗?

说的合情合理,这2点我都赞成。 但是实践起来难,尤其企业级团队开发,除非团队有人协调。 同意楼上的,开源项目可能会好点,但商业项目有点难 看了链接的文章,方法倒不难,也在做。 问题是前人栽树后人挖坑,这种事情得要立规范,类似于《日志打印规范》,否则一个项目过了N多人的手别说日志啰混乱的一批就连变量名都猜不出是什么含义了[白眼] @只等闲 正解! 不止要立规范,代码提交也要把关。这样才能避免日后不必要的麻烦 日志打印往往在一个时间较为紧急的项目中被忽视,而你可能会发现,我们遇到的项目,周期都不怎么松。而且实际上有没有日志,功能照样能实现,还节省了很多时间,正如单元测试的性质一样,它可能会延长项目时间 日志太多太少都不行,打印关键日志就好 但是,正所谓,慢就是快,想想,我们的维护时间往往是项目周期的两三倍以上,而维护的对象本质上是什么呢?就是我们写好的代码,若代码中缺少必要的日志打印,或者打印的日志过多过频繁,不仅不好定位问题,还有磁盘存储爆满的问题出现 慢就是快[强],确实是这样的,后期的无法维护所耗费的时间跟精力,不如全部重构,而这导致的时间成本浪费是巨大的 @tree 我觉得是不是可以在项目后期,重构阶段把日志也重新规范起来,代码与日志规范重构当做一个独立的任务进行,从整体上让项目后期的升级迭代变得可控 这些瘦身方法并不复杂,比方法更重要的是团队意识,以及流程控制上是否能更好的落地与执行,这才是正途。 没这么复杂吧,spring不是可以控制日志的各种级别 debug、info、warn、error等,还能屏蔽指定包的log,这些还不够吗?合理的运用这些,把多余的log去掉。 把日志当做功能代码的一部分,很重要。 线上服务少打点log吧?影响性能! 论测试的重要性

全部评论: 0

    相关推荐