代码为什么要review?
以为代码比较少bug，其实是这样的画风：
如果代码前期不提高质量，程序猿后期就可能会有这样酸爽的体验：
所以为神马要对项目代码做代码评审（code review）呢？一方面，直接原因是可以提高代码质量，将bug在开发过程中，测试前就给它揪出来；另一方面，团队协同作战，制定的代码规范怎么实施下去呢？code review也将是一个很好的措施，可以渐进的形成统一的编码风格，提升团队协同开发整体作战水平，并对于形成协同互动的团队文化产生积极促进作用。why？
都Review些啥呢？
具体要Review哪些内容呢？这个问题貌似永远没有绝对正确的答案，每个开发团队都应该对自己的方法达成一致。所谓达成一致，团队成员需要一起制定代码规则以及Review的checklist（检查项列表），切忌由某一个人制定规则：
代码评审是需要无差别化，要一视同仁，即便是团队中最资深的人也并不意味着他的代码不需要评审。即使在极少数情况下代码是无瑕疵的，审查也提供了一个指导和协作的机会，并且加深团队对代码的理解。
具体实施可从两个方面着手：
啥时候Review?
代码审查应该在自动检查（单元测试、代码风格、持续集成构建）成功完成之后进行，但是应该在代码合并到代码库的主干（或者叫mainline或者叫trunk）分支之前进行。
为什么要在这些自动检查成功之后才Review？因为这几个过程都有可能发现问题，并触发修改代码，所以Rview一个相对稳定的版本将会减少重复Review的工作量，节约时间。那么为什么要在合并到主干之前审查呢？这显然比较好理解，因为这样可以尽量将高质量稳定的版本或者功能合并进主干，可以保证主干的相对稳定以及质量。
该怎么Review呢?
发起Review的代码提交者，需要提前做好准备工作，从而提高效率，以减少浪费其他参与人员的时间：
具体Review时，有哪些值得推荐的做法呢？
总结一下
良好的代码审查机制，将有助于提升代码质量、减少产品缺陷、降低开发成本，同时也有助于持续提升团队凝聚力、建立更好的团队协作文化、提升整体的作战能力。而形式化的代码审查，则将浪费成本、影响士气。至后台发送CR，领取checklist
本文辛苦原创，如喜欢请点赞/在看/分享支持，不胜感激！
本文分享自微信公众号 - 嵌入式客栈（embInn）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。