最近被要求做一个关于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、重复的代码
3、其他问题
a、缺少验证和异常处理。例如不对数据进行验证，或者不处理异常又或者捕获无法处理的异常
b、对工具和框架的错误使用。例如有的ORM框架提供非常方便的运行时延迟加载功能，方便倒是方便，滥用却会有性能隐忧
c、缺少可读性。注释和命名规范是一个问题，不过过深的调用层次都会影响代码可读性。
d、缺少扩展性。例如在没有DLR的情况下在业务层使用匿名对象。
e、缺少安全控制
f、性能隐患。例如在C#中使用了非托管资源而没有进行释放，或者说有过多、过于频繁的I/O访问
4、测试问题
a、没有测试或者覆盖度不够
b、测试代码滞后，在更改逻辑后没有对测试进行同步更新
以上是一些通常的Code Review的内容了。当然这里再强调一点的就是规范的完备性，和开发过程的成熟度。Code Review是一种相对高级软件开发活动，没有必要一定要执行。不过一旦实施成功将会有巨大的回报。
在实施过程中还有一些心得：
1、做好准备。如果对项目很熟的话，应该知道哪些地方会有问题，Code Review是重新审视和从内因上解决这些问题的良机。
2、不要考虑业务逻辑。完全专注于代码的实现，例如算法的效率，抽象的粒度。整个代码体系结构的平衡性
3、虚心学习。不要有针对性
4、在原则和现实之间平衡。不可能所有事情都完美，所以有的时候我们坚持原则，有的时候修改规范。
5、不要让自己Review自己的代码
6、总结跟进Review的结果，并且坚持开展这个活动。这才是最重要的