再谈Code Review，我有一些不一样的见解

已有的utils方法，重复造轮子

代码过于复杂，缺少必要注释，后人难以维护

目录结构五花八门，杂乱不堪

……

有利于帮助新人快速成长，团队有新人加入时（如实习生和校招生），往往需要以为导师带领一段时间，通过CR环节，可以使导师最直接的了解到新人开发过程中所遇到的问题，作出相应的指导。

通过CR环节，团队成员可以了解他人的业务，而不局限于自己的所负责的业务范围。项目发现问题时，可以迅速定位到相关业务的负责人进行修改。同时若有的团队成员离职后，也可以减少业务一人负责所带来的后期维护困难。

学习他人的优秀代码。通过CR环节，可以迅速接触到团队成员在项目中解决某些问题的优秀代码，或者使用的一些你所未接触过的一些API等。

指明review的级别。reviewer再给相应的代码添加评论时，建议指明评论的级别，可以在评论前用[]作出标识，例如：

讲明该评论的原因。在对代码做出评论时，应当解释清楚原因，如果自己有现成的更好地解决思路，应该把相应的解决思路也评论上，节省reviewee的修改时间。

平等友善的评论。评论者在review的过程中，目的是提升项目代码质量，而不是抨击别人，质疑别人的能力，应该保持平等友善的语气。

享受Code Review。只有积极的参与CR，把CR作为一种享受，才能将CR的价值最大化的体现。

注重注释。对于复杂代码写明相应注释，在进行commit时也应简明的写清楚背景，帮助reviewer理解，提高review的效率。

保持乐观的心态接受别人的review。团队成员的review不是对你的批判，而是帮助你的提升，所以要尊重别人的review，如果review你感觉不正确，可以在下面提出疑问，进一步解释。

完成相应review的修改应当在下面及时进行回复，保持信息同步。