最近被要求做一个关于Code Review的讲演。首先要说明的是，我并不是太擅长开展Code Review的活动。做这个完全是因为答应了别人又不好反悔。不过在做准备的过程中还是有一些感想。

　　关于Code Review我所了解到的行业中最著名的是Bill Gates汇报。这是微软在软件开发过程中的一个重要环节，因为Bill Gates亲自参加而备受关注，在行业中广为流传。

　　Ok，进入正题了。

　　我们面临的共同问题：

　　1、对于开发周期较长的软件项目，可维护差的代码对项目造成了极大的困扰

　　2、结构复杂的，体系不清楚的代码会导致新成员或者外部干系人很难融入。

　　3、软件项目代码质量低下，Bug众多并且有关联累积效应。

　　以上三个问题是我在以往的Code Review活动中总结出来，可以被影响或者解决的问题。也就是说我的观点是如果没有上述问题，或者在目前的软件产品的规模、开发过程的成熟度还没有达到一定级别时Code Review是可以不做的。当然优秀的开发人员会做自我审查，这是另外一个问题了。

　　总而言之，我认为开展Code Review活动的前提是

　　1、开发过程和质量控制达到了一定的成熟的。

　　Code Review必然与重构相关联。如果开发过程中更本就没有重构这样的活动，那估计Review出来的结果不太容易得到执行。

　　其次是各种标准和规范的齐备性，没有规矩是不能成方圆的，如果只有一个命名规范，那可想而知Review的内容不会太深入，效果因此大打折扣。

　　2、代码达到一定那个的规模一般来说，功能单一的小型项目的体系结构不会太复杂。不太会出现Bug的累积效应。小型项目完全可以通过daily meeting和Test来保证。

　　Code Review并不是一个随便就可以做，或者做了就有好结果的活动。不过无论如何，一旦条件成熟或者资源充足都应该积极的开展Code Review的活动。因为它除了进行质量控制以外，还是一个团队成员之间进行沟通和相互学习的好机会。

　　Code Review的内容：

　　1、代码的规范性

　　　　a、混乱而散漫的命名，例如使用a、b、c这样的单字母对变量进行无意义的命名

　　　　b、随处可见的magic number或则hard code。软件中const在所难免，不过这些const应该被集中管理起来。而不是可以随意、随处的出现

　　　　c、缺少注释，或者注释不完备甚至错误

　　2、代码的结构问题

　　　　a、巨大的类或者巨大的方法

　　　　b、过于复杂的实现

　　　　c、紧耦合

　　　　d、重复的代码