背景
公司从18年开始使用git协同工作流，从最初的试点到全员推广使用，我全程深度参与；最早是从onu项目开始使用，以前我是知道git但是没有协作使用过；刚开始使用，提代码的过程很是虐心。被“羞辱”地很厉害！发生了很多笑话，后面啃了不少资料、不断实操才能说有点通；那时候代码都是不review的，只是有个MR过程，我也不懂什么是Code Review；现在回想当初，印象中就是被不断地批评代码有xx问题，挫败感非常强，提的问题大部分不理解，即使修改了再提交也很难被合入；两周下来，“进度”被阻塞地很厉害，大家抵触情绪很高；现在回想感觉非常羞耻的是，我经常为了“进度”就得去“搞定”合代码的人；在后续项目组也保持了这个制度，这个过程还加入了些工作流，编译静态检查，合入编包归档等动作；最近又回到起始的地方，发生了一系列摩擦，让我重新思考这个问题；我下面所说的就是我所认为的——即个人观点，也不是为了把自己摘出去站在道德制高点“喷”大家，仅记录一下，供自己以后所用。
我理解的现状
- 虽然一直在做Code Review，但是我没有持续不间断的用心投入做这个；
- 我可能内心认为Code Review没有想象的有用，做出来更重要，做漂亮不重要；
- 评审中涉及修改变更老代码的部分，单纯评审变更没有意义，因为代码是有上下文的；但是整体来评审让其修改，又会有新的变更风险、人员情绪等问题，这令人十分沮丧；
- 评审代码很耗时间，反复几次容易产生矛盾，而且即使修改后效果还是不尽人意的，妥协了很多我认为我所坚持的东西，标准一直在降低；
我是怎么看待的
- 这个过程没有太多的交流、碰撞，我觉得很无趣；现在的这种方式是双方都觉得很被动的方式，双方沟通交流接触过少，存在很多臆想误区；
- 之前有个pm质问我：你review代码根本发现不了业务问题，因为你业务不精通，还不如测试的效果好；后面我查阅了些资料才知道这是个误区，Code Review不应该承担发现代码错误的职责，Code Review主要是审核代码的质量，如可读性、可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该是由单元测试、功能测试、性能测试、回归测试来保证的。我们过度神话了这个过程。
- 评审变更涉及部分这是必要的
- 评审者提的疑问下一个阅读者也可能会有此疑问，说明这个代码可能有歧义；
- 代码是要被玩转的，敢于修改的，不敢修改的代码肯定会腐朽的很快；
- 代码是无署名的，但修改旧的代码需谨慎，最好让目前组中最熟悉的人参与一起review；
- 我对现状保持消极态度，质疑别人的能力，有“做不好”这个预期；
我应该怎么做得更好
- Code Review要短、非正式；抛弃评审中的checklist，对于有意愿写好代码的，要下去和其交流，提疑问；
- 不能太依赖线上的discussions ，线上交流失真效率低；
- Review只是一种形式，只有在相互信任前提下彼此的讨论才能得到有意义的结论。要禁权威，避免让Review变成流程性、礼节性行为，双方是在探讨交流，关系是平等的；
- 应尽可能做好平时的Review，避免一次Review代码过多，这样效率低，需要重构、重写的代码更多，口水战更多；越接近发布期限，代码修改也不能改得太多，应避免；
- 保持积极正面的态度，程序员很容易“自负”，尤其当Review别人代码时，会情不自禁抨击别人的代码，质疑别人的能力(靠指责他人表现自己肯定是“半桶水”)。