![Snip20180703_116]()
今天在浏览网站的时候，看到别人发的这么一个帖子，刚刚入职一个新公司，代码审查的时候，leader 对他的代码进行了一些修改，而这个程序员感觉很多地方没有必要，你们看完上面这个帖子什么感觉?
看法
我看的看法是：
一是，遇到这样的领导真的很好，咱先不讨论领导这样的修改，有些地方是否有没有必要，光看领导这么事无巨细的在这些小地方都帮你 code review 进行一些修改，就说明领导非常负责，领导的这些修改和你的哪个更规范?这个不好说，但是领导的修改我个人认为确实很规范，最起码没错。
二是，我认为确实领导的一些修改没有必要。就比如：上面的那个我画红框的地方，把 setVisible 换成了 show ，其实没必要，但是我认为领导的那个更容易让人看懂和辨识。还收上面的那个常量的命名，领导也给修改，其实确实也是没必要的地方。
还有一个地方比如：a.do1() a.do2() ，领导给修改成 a.do1.do2()，或许没必要，但是领导的这个修改可以让代码更简洁，看起来更方便，在维护代码和更新迭代上来讲，确实让你一眼就懂，很清楚，方便整个团队工作的管理和交接。
想法
其实，作为一个团队来讲，首先看看整个团队有没有代码规约和规范，里面是怎么规定这个变量，常量，方法函数的命名的，如果这个团队里有代码规约就是这么制定的命名规则，我们还是应该按照这个规则来命名。
你想想一下：
一个团队的 leader 下面十几个人，你是想让领导适应十几个人的风格，还是让十几个人统一到领导的风格?
代码风格和规范统一了，才利于整个团队代码的维护和交接，有利于代码的管理和升级。这就要求团队必须有一个代码规范。欢迎大家关注我的微信公众号：非著名程序员
比如：上述程序员，不满意领导的修改，你先看看团队里有没有代码规范，代码规范是对于命名是怎么规定呢?如果有，是你没有按照规范来使用，那就是你的问题，如果没有规范，那你可以找 leader 谈一谈，团队应该制定一个规则，能否出个规则，以后我按照这个规约来写，也可以减轻领导 code review 的工作量。(http://godcoder.me/)
代码评审
为什么要进行代码评审?
- 提高质量
- 及早发现潜在缺陷与 BUG，降低事故成本。
- 促进团队内部知识共享，提高团队整体水平
- 评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。
其实，我认为代码评审，不仅仅是领导的事，每天抽出一个小时，团队里每个人都对其他人的代码进行评审也是非常好的，不仅可以找到各自身上写代码的缺陷和毛病，还可以学习别人写代码的优点。毕竟评审过程对于评审人员来说，也是一种思路重构的过程。欢迎大家关注我的微信公众号：非著名程序员
另外，整个团队必须要有一个明确的代码规范和规约的好处是，code review 应该是做重要的事，而不是花在这些不规则的命名上，命名的事，让规约来约束大家，code review 最重要的是提高代码的质量，发现潜在缺陷与 BUG，寻找项目模块中不合理的地方，比如：系统关键模块，业务较复杂的模块，缺陷率较高的模块等。
***，我想说，截图上的那个领导，确实水平很高，光从命名上来讲，确实很规范，虽然可能有点较真和过了，但是确实值得学习。
