程序员在代码审查时，遇到这样的领导是好是坏？

今天在浏览网站的时候，看到别人发的这么一个帖子，刚刚入职一个新公司，代码审查的时候，leader 对他的代码进行了一些修改，而这个程序员感觉很多地方没有必要，你们看完上面这个帖子什么感觉？

看法

我看的看法是：

一是，遇到这样的领导真的很好，咱先不讨论领导这样的修改，有些地方是否有没有必要，光看领导这么事无巨细的在这些小地方都帮你 code review 进行一些修改，就说明领导非常负责，领导的这些修改和你的哪个更规范？这个不好说，但是领导的修改我个人认为确实很规范，最起码没错。

二是，我认为确实领导的一些修改没有必要。就比如：上面的那个我画红框的地方，把 setVisible 换成了 show ，其实没必要，但是我认为领导的那个更容易让人看懂和辨识。还收上面的那个常量的命名，领导也给修改，其实确实也是没必要的地方。

还有一个地方比如：a.do1() a.do2() ，领导给修改成 a.do1.do2()，或许没必要，但是领导的这个修改可以让代码更简洁，看起来更方便，在维护代码和更新迭代上来讲，确实让你一眼就懂，很清楚，方便整个团队工作的管理和交接。

想法

其实，作为一个团队来讲，首先看看整个团队有没有代码规约和规范，里面是怎么规定这个变量，常量，方法函数的命名的，如果这个团队里有代码规约就是这么制定的命名规则，我们还是应该按照这个规则来命名。

你想想一下：

一个团队的 leader 下面十几个人，你是想让领导适应十几个人的风格，还是让十几个人统一到领导的风格？

代码风格和规范统一了，才利于整个团队代码的维护和交接，有利于代码的管理和升级。这就要求团队必须有一个代码规范。

比如：上述程序员，不满意领导的修改，你先看看团队里有没有代码规范，代码规范是对于命名是怎么规定呢？如果有，是你没有按照规范来使用，那就是你的问题，如果没有规范，那你可以找 leader 谈一谈，团队应该制定一个规则，能否出个规则，以后我按照这个规约来写，也可以减轻领导 code review 的工作量。

代码评审

为什么要进行代码评审？

1、提高质量

2、及早发现潜在缺陷与 BUG，降低事故成本。

3、促进团队内部知识共享，提高团队整体水平

4、评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。

其实，我认为代码评审，不仅仅是领导的事，每天抽出一个小时，团队里每个人都对其他人的代码进行评审也是非常好的，不仅可以找到各自身上写代码的缺陷和毛病，还可以学习别人写代码的优点。毕竟评审过程对于评审人员来说，也是一种思路重构的过程。

另外，整个团队必须要有一个明确的代码规范和规约的好处是，code review 应该是做重要的事，而不是花在这些不规则的命名上，命名的事，让规约来约束大家，code review 最重要的是提高代码的质量，发现潜在缺陷与 BUG，寻找项目模块中不合理的地方，比如：系统关键模块，业务较复杂的模块，缺陷率较高的模块等。

最后，我想说，截图上的那个领导，确实水平很高，光从命名上来讲，确实很规范，虽然可能有点较真和过了，但是确实值得学习。

文章首发于微信公众号：非著名程序员，关注我，每天与 10 万开发者共同进步，你离成功，只差一个关注。