应该对于基本上所有软件相关的公司来说，都有committer机制，即代码写好之后会提交合并请求，待相关人员code review通过后再进行合入，所以code review就是代码合入代码仓库的最后一道关卡，对于代码质量的影响也是不容忽视的，那么作为在华为、阿里等大厂担任过committer的老code reviewer，我在code review关注哪几方面的东西呢：
- 代码风格
比如命名是否正确、函数抽象是否合理等，这些影响代码后面的可读性。在我刚从学校毕业的第一份工作的第一个项目中，那时候还保持着在学校里面的思维，就是代码只要实现功能就行，所以命名各种a、b、c、test之类的，函数抽象也不注意，这样当然不会影响功能的实现，但问题是，商业产品的代码是有一个漫长的维护周期的，当你实现的功能不可避免的出现问题的时候，麻烦就来了。当时我第一个项目交付之后半个月，就遇到了一些功能上的问题，需要我去改下代码，这个时候我去读我半个月前写的代码，已经完全读不懂了，看到那些a、b、c、test的变量名，完全不知道这个当时是想拿来存什么的；好不容易看懂一点，需要改的时候，因为函数也没有很好的规划，导致一个功能点需要霰弹式的修改很多地方，维护起来异常困难。从那次经历以后，我就知道软件工程远远不是实现功能这么简单，可读性、可维护性也会是其中的重要一环。
- 是否有逻辑问题，比如无法退出的for循环之类的
这种最好也能在code review这一环节就被检查出来，方法也非常简单，看到任何循环语句，比如for、when、while的时候多留一个心眼，看一下循环条件判断语句有没有恒为true的情况，特别是那种不在循环条件里面写循环条件（设置循环条件为true），而是在循环体里面去设置不满足条件时再break的情况，这种要特别留心看下有没有可能无法跳出循环。
- 是否有资源泄漏的风险
这个比较难一点，需要对当前所使用的技术栈有可能造成内存泄漏的方式有所了解，比如C++有没有锁申请了没释放、有没有从堆上申请了内存没有释放；golang有没有把切片的一部分作为一个切片返回出去，比如把一个长度为1000的切片的前10个数据作为一个切片返回出去，比如a[:10]。
- 流程完善
除了人通过肉眼code review外，还可以增加各种辅助检查工具，比如一些静态检查的lint，或者提交以后自动跑一次编译，避免合入以后引入编译问题。
- speed and performance
当前代码构造的方法是否足够合理，是否是性能最好的方法，可以通过大O表示法来进行一个大体的判断，同时也可以判断一下圈复杂度是否过高。
- 是否重复造轮子
这个要分成两部分来说。一是对于已经有的轮子，就不要重复去造一个了；另外就是如果提交的代码里面多次出现一段代码，考虑把它造成一个轮子，也就是抽象成一个函数，而不是在多个地方把它写多次。
- 可靠性（容错性）
如果发生错误的话，这个地方是否会崩溃？是否能比较好的抛出有意义的异常？
- 是否有冲日志的可能
是否会大量打无意义的日志，导致日志被冲掉，影响正常定位问题。
- 是否有错误被抑制了
这个是最微小、最容易被忽视、却又影响很明显的一点。错误被抑制是我自己定义出来的一个术语，大意是说错误没有正确的被展示。具体内容可以关注我的另外一篇文章：使用golang的AST编写定制化lint_golang lint-CSDN博客
最后，祝大家提升代码工程质量之后能早点下班，不用加班来填质量的坑~
