我对Code Review的理解

一. Code Review的前期准备

1. 前提条件：code review的大前提是，是否自己已经认为这份代码已经优化到了极致，如果还没有，那么说明还没到code review的程度，先自己优化优化，效率可能反而还高些。这样确保真正在code review的时候，别人提的意见都是自己没有考虑到的，而不是自己其实也考虑到，只是还没来得及改或者懒得改。
2. ppt：每位同学需要对自己的代码做前期规划设计，展现形式不限，可以不用标准的流程图或者类设计图等软件工程的东西，但唯一目标是希望能够通过两三页ppt，用简单、清晰的语言描述清楚自己的代码设计逻辑。
3. 在code review之前需要先完成1和2

二. Code Review的检查工具

目前推荐的是通过pylint来进行整个工程的检查，除非有很多其他外部依赖的代码需要手工排除掉的。

  There are 5 kind of message types :
  * (C) convention, for programming standard violation
  * (R) refactor, for bad code smell
  * (W) warning, for python specific problems
  * (E) error, for much probably bugs in the code
  * (F) fatal, if an error occurred which prevented pylint from doing

1. 代码执行需要集成pylint或cpplint工具的评价，超过8分以上代码才能接受上线和合并。
2. 大家安装统一版本：

   pip install pylint==2.6.0

   pip install yapf==0.30.0

3. 检测步骤：
   1. 通过pylint对整个工程进行检查(pylint project)，也可以对具体某个python代码文件进行检查(pylint code.py)
   2. 使用yapf对代码进行快速格式化，有助于快速改良代码的整洁程度(eg: 对整个项目工程进行代码格式化：yapf -r -i -p ./template/，  对某个具体文件代码格式化：yapf -i code.py) 
   3. 按照pylint的结果提示，逐个修复代码中存在的问题
   4. 返回步骤a，直到pylint分数达到8分以上

三. Code Review的形式

CR活动有很多形式可供我们选择，我们可以根据实际情况选择桌面式CR、演示讲解式CR、一对一的座位CR等等。(一般按新增功能桌面式CR、里程碑功能演示讲解式CR、BUG修复一对一的座位CR)

我们优先选择里程碑功能演示讲解式CR，代码编写者就事先准备好的ppt，给大家做一次分享，这个代码的设计原理，碰到的问题，怎么解决，为什么这么解决。

初衷是希望把code review的会议也能作为一次技术交流探讨的好机会，不用严肃到像是在晋升答辩，希望在气氛相对放松的情况下进行，有利于大家各抒己见，说错了没有关系。

四. Code Review的步骤

1. 代码编写者和代码审核者坐在一起，由代码编写者按照UC依次讲解自己负责的代码和相关逻辑；
2. 代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug；对这些bug记录在案。
3. 代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。
4. 代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。
5. 代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。
6. 代码编写者 bug fix完毕之后给出反馈。
7. 代码审核者把Code Review中发现的有价值的问题更新到"代码审核规范"的文档中，对于特别值得提醒的问题可群发email给所有技术人员。

五. 可参考学习的工作积累

1. 用YAPF让Python代码瞬间从丑陋变漂亮

2. 为什么我非常不提倡在程序里用缩写

3. 如果坚持使用缩写，推荐先看看：编程变量命名规则及编程单词缩写字典 

4. CodeReview规范

5. protected变量和private变量命名的区别