CR代码 | wxya

🗒️CR代码

type

status

slug

date

在开源社区到很多pr，提成意见改动的时候，都会用一些鼓励的话，比如：

Great job!

干得好！

Here are some suggestions of improvements:

以下是一些改进建议：

如果我们在在CR的时候加上，是不是会更加友善一些？

双方互相学习（规范也好、探讨也好）

nacos代码里面还有hashMap初始化数量错误的问题，但是影响使用么？对性能影响多少？很多时候真的有必要吹毛求疵吗？——不过提出来了就值得学习一些，反正是对自己好。

23年腾讯有个文章，说cr就是群里@一下，5秒后回复done就结束，讲的是业务复杂性带来的代码不可维护

优化优势有度的，要根据实际情况和维护能力来，如果自己和大家维护起来完全没有问题，那就可以过；

大家理解起来费劲了就是需要优化了；

也要注意不要过度优化

大家也可简简单单蒙混过关，我见过的大多数也都是这样，但是利于成长么？遇到认真CR的人，对于大家来说都是一件好事情

开源社群争吵也不过是正常现象，自己学习到就口价哦

前端eslint

后端java 阿里巴巴插件

加上提交前检查，和提交代码后github自动代码扫描，通过工具解决，这里要减少人为处理

甚至可以找到一些AI插件，提前CR代码，提出问题和修改意见（gitlab AI插件，或者是自己公司实现的工具链路）

减小改动范围（依赖、构建环境、环境非必要不更换）

有时候为了修复问题，一次升级好多不相关依赖，实际上没有必要

没有明确要解决什么问题，盲目变更会带来位置风向

这个就要看你业务知识丰富不丰富，如果你除了代码，业务的事情一点都不了解，怎么来判断这个问题？

cr的人，基本是长期对整体代码有过了解的，新同事不熟悉的同事，写的时候难免有局限性，要给予提示

偶尔问一句，也许会避免一些问题

还是要遵遵循非必要不改动

我见过一个日志输出原本可以用，个人知道因为什么原因修改为日志输出为滚动打印，导致Filebeat占用磁盘不释放，修正后因为没有ci环境配置等查看权限，最后过了一周才发现日志没有收集，原来不仅改了代码的日志输出配置，还修改Filebeat的收集文件

个人也经常犯这个错，修改的时候要忍住

不合理的语义

绕弯弯的代码

类型的不统一

注意保持保持上下文统一：比如方法变量多次传递，名字慢慢就变了（多个系统多语言更是如此，名称、类型都不统一查看问题费劲的很）