看的我头皮发麻
实现方式有很多呀
没有吧，都在相互否定还怎么出结果呢。。。
我们一般 Merge Request 记录评审结果，评审有可能 2 人面对面或者整个小组公开评审。不过评审前肯定要先按规范文档自审，避免浪费时间在如变量命名不规范这类小事里。
就像阿里的代码规范一样。如果代码能力弱，可以先从简单的命名规范开始，慢慢的考虑结构化，需要不断地 REVIEW,不断的加强规范。
我自己做过代码评审，一般评审的规则要心里有数，大概会看一下其他人的业务逻辑。不是特别离谱的，有时候也会睁一只眼，闭一只眼。
而且 GOOGLE，微软都有行业的编程规范。
如果完全没规范，有些逻辑差的写代码不得上天了？
最后越牛 B 的人代码越规范，结构化越好。
代码 review 主观性很强，一人一个看法很正常。
所以这就需要有一个拿结论的人，一般是经理甚至总监，一个人就够了。
review 主要是看代码规范，如魔鬼数字，注释，过长的方法，公共方法的抽取，定义公共变量，是否按要求提示，异常的捕获，父类子类继承覆盖等等。其次还要看关键算法，举例比如是向后循环还是向前循环更优，用什么数据结构更好，是不是用多线程异步执行等等。还要看对系统的影响，比如内存占用是不是合理，内存回收策略，CPU 会不会高占用，对 GC 的影响等等。还要看架构的使用，比如查询比较这种可以直接使用数据库查询出来而不能程序遍历比较，常驻内存数据可以放到外部存储，异步队列执行，异常重启数据的恢复等等。
要举例的太多太多，往往你说的否定我写的，我否定你写的这类都是在代码规范上较劲儿，看着还是比较低端的。相信成熟的 review 中，整个 team 都会沉浸在技术的最优解上，劲儿往一处使，都会有收获。
但是这种 review 也有几个弊端，一是容易看出来一个人的水平高低，这对领导往往是致命的。二是比较费时间，节奏不好很容易开成大会浪费生命无意义。所以没有 review 我表示理解。
对于测试来说，review 都是开发自己的事情，我比较无所谓。
陈恒捷
回复
我们是有规范的，review 之前先根据这个规范自检，然后再分配别人去检查，但是我这检查的时候，太多的错，逻辑上你调不通没问题，但是基本的规则自己是能 review 出来的吧....看的真的头疼 ，要么逻辑不对，要么各种不对 。
