code review 流程规范

目的

• 提高代码质量，及早发现潜在缺陷，降低修改/弥补缺陷的成本
• 评审过程对于评审人员来说，也是一种思路重构的过程，帮助更多的人理解系统
• 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码
• 促进团队内部知识共享，提高团队整体水平
• 鼓励相互学习对方的长处和优点

其他配置文件 -> 入口文件 -> 公共模块组件 -> 页面

• 4.代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug，或一些优化建议，对这些bug和建议记录在案
• 5.代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。
• 6.代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出

代码审核报告模板

注意事项

• 经常进行Code Review

  • 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。
  • 程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。
  • 越接近软件发布的最终期限，代码也就不能改得太多。

• Code Review不要太正式，而且要短

  • 抛开代码审核的检查要求，代码编写者像请教师傅问题一样，给师傅们讲讲自己的代码，然后给师傅们点时间给自己的代码提提意见。
  • 不要过于正式，大家随意点，正常学习交流一样提出疑惑和建议。不然就会出现下面的情况
    • 把code review当做是一个任务去完成，平时开发中就很少去听取别人意见去修改
    • code review变成一种正式任务的时候，你的同事也许会假装很关心你的代码，但心里想早点结束离开你，这样就不会提出好的建议
  • 只有不太正式的，当做交流会一样，大家放松去交流和发表意见，人放松了，才会很真实，真诚的去说出心里话。
  • code review只是一种形式，主要目的是大家通过项目代码互相讨论，得到了有意义的建议，才是最实在的，
  • 不然作者和审评者的关系变得很尴尬，感觉像在挑刺，找茬，这样的气氛就不好了。

• 保持积极的正面的态度

  • 无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；
  • 评审者也需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。

• 学会享受Code Review

  这可能是最重要的一个提示了，如果你到了一个人人都喜欢Code Review的团队，那么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，你不需要上级的管理，团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，形成一个凝聚性很强的团队。