另外你看看 last 的 man page 我记得很多选项可以看从某一时间以来的记录. since 还是什么的

你指的风险是什么?
有人登录你的服务器然后你不知道? 还是什么

我觉得是 strategy pattern 的 use case.
但描述太简要, 无法确定.
后端一个 strategy manager 可以根据前端传过来的(不一定是类的 qualified name) token, key 等, 来选择 strategy 进行逻辑计算.

真听, 真说, 真读, 真写

@jjianwen68 生产系统一般没有设置 debug 的. 不是文件大点, 是可能把硬盘撑满的问题. 还有就是安全性, debug 可能把 object 都打印出来.

log 有不同的 level, 这个基本各种语言都是支持的.
你本地开发环境随便你怎么弄,
dev 的 stage, 一般都是 debug lvl
test 的 stage, 一般也是 debug, 但是为了跟 Prod 的完全一致, 比如出错误排查情景也要模拟, 也可能跟 Prod 的 lvl 一样
prod 的 stage, 看你们的要求了, 一般是 info 这类的
日志非常有用, 比如当你的应用出问题了, 通过日志信息会快速定位问题.

@lxzsunv 哦.. 我对整个实践其实了解的稀里糊涂的.... 没花时间去看, 也不知道具体是怎么回事, 就知道是个公司, 员工之间的纠纷, 后来还关起来好像 200 多天, 可能误解了. 对不起.

"用了 vim, emacs 就是垃圾
我用 python, 看 java 都是幼儿园
我用 linux, macos 用户都是傻瓜型
一切键盘解决, 只有小白才用鼠标
GUI 程序...看看终端程序才知道什么是效率..."

各个不同的东西都有特点, 如果真的深入了解了这些不同的特点甚至各自的长短项, 就不会有上面这些言论. 只有刚入门半瓶水才会这么说. 人家讨论 java 的话题, 就研究 java 瞎这么比没意义. 要是一个做生意发财的看到这个帖子, 也可以回复:" 自从做了生意, 才知道搞这些代码真是浪费生命, 劝你们别过垃圾人生了."

@pence2019

我还是重复, 强制所有 method 加 javadoc 是不明智的.
当然, 如果你们的产品是个 library, 那么至少所有的 public methods 都应该有 javadoc
我猜大概率你们的也是 enterprise application 这种东西, 那么 javadoc 就是给自己人看的, 尤其是以前的程序, 自己人再修改过程中也就体会了哪些比较难理解, 读懂加个注释为什么这些代码这么做, 就好了. 至于那些很明显的就不用再写 javadoc. 作为一个好的项目, 除了代码精妙以外, 没有没用的注释, 而且存在的注释都有存在的价值, 也是个特征.
举个例子, vim 编辑器的代码就不是好代码.

@pence2019
还是不懂, 改的模块, 类? 你意思就是这个项目的方法以前没有 javadoc, 现在都要加上是么?

有.现在很少有没有 review 的吧.

所有路过的方法... 什么叫"路过"的方法?
如果是指所有方法, 强制所有方法都加 javadoc 是不明智的.

swagger 的页面有 bug, 单击了 try it 以后, cpu 会飙升, 然后取消, 又恢复.
说到工具, 我没找到比 insomnia 更好的.

LZ 这个问题跟书的质量关系不大.
但是中文技术书籍不管原创的还是翻译的, 质量差的是大多数. 有时候翻译的人本身都缺乏该领域的经验.
现在技术资源在网上都挺多的文章. 如果非要看书, 选择国外的原著经典书. 技术的英语很容易, 别上来就怵头, 看几章再说. 比翻译的强不知道多少.
举例一下, 20 多年前, 我读过机械出版社的 thinking in java. 这个都知道吧? 蓝绿封皮的, 翻译的烂的不行, 根本看不下去　还是花好像 80 来欧买了本原文.

SO 都有关闭理由, 每个 closing vote 都会选择一个. 我看到你的问题, 也会 vote to close, 应该是 Needs more focus.
你应该读 SO 一篇怎么问问题, 问什么问题的问.
stackoverflow 是解决具体问题的, 不是这种大的. 就像, 我问"how does jvm work; how does java time api work...."
其实你可以变通, 弄一个小例子... 然后把你要知道的问题通过这个例子引申过去, 这样从这个具体例子出发, 人们就会解答你的实际问题. 这样还一个好处就是, 可以屏蔽那些非常浅显的解答, 因为当人们读了你的问题了解你的真正疑惑, 再单纯解答你的例子问题就没意义了.

虽然大部分时间都在答题, 问的很少, 但是看的问题多了, 也有点"经验", 希望对你游泳.
my 2cents.

@lxzsunv 你说的是 huawei 什么的那个事?　网上太多, 就像春节的庆祝, 不看也会了解到.
中国 IT 公司的状况, 就是那个情况, 我其实没怎么关心, 996 什么的只是笑笑倒转历史车轮罢了. 具体事项没怎么深入了解.
但如果真正死磕, 音频在法律层面不能成为有力证据.虽然影视剧对于这个有不同理解.

从配置好运行到现在 2 个月, 还没重启过. 下载过大时热点, 别的很好.

https://imgur.com/QVqI7GS

打不开. 需要翻墙吗?
我是说, 翻到国内?

录音是不能作为严格意义证据的, 剪辑太容易了. 我们听到的录播新闻广播, 主持人念错了, 不是重新念, 就接着念, 最后再一剪辑就成了. 通话录音也是如此. 当然如果背景音比较复杂, 剪辑难度就大些, 否则听着太明显像剪过的. 还有变声处理也相对容易.
但是录音可以提供一些信息, 也仅此而已.

逐行审视自己做的修改是对的. 就像你做个东西, 起码自己满意了再提交给别人 review, 甚至业务人员测试. 当自己都不确定是不是自己最满意的东西, 拿给别人, 再反复 pingpang, 只能说明自己不认真.

这样当自己最满意的东西被别人找出问题, 而且不是吹毛求疵那种, 才会真正学到东西.

剩下的, 应该有测试, 不光 unittest, 还应该有自动化的 integration test.