为了培养团队对代码质量的重视，我组织了一个长期的代码审查计划。每次审查，我都精心挑选400行左右的代码，邀请一名开发人员预先阅读代码，控制会议时间在一个小时，同时通过角色互换让每个人都有机会担任主持人、代码作者、以及评审人员的角色。尽管如此，效果却极有限，也暴露出许多的问题。

首先是前后台脱节的问题。项目采用前后台分离的组织架构，通过约定服务接口，分别对各自的架构、组件和代码负责。后台开发人员有四个人，为了促成代码审查，我邀请了两个前台开发人员一起参与代码审查。结果是前台开发人员对于后台代码审查几乎没有什么贡献，而当我提议审查前台代码时，对方也极力推托，不十分配合。

其次是代码分布不均衡的问题。事实上后台代码的80%都是我写的，所以为了让每个人都能感受到审查的好处，我不得不选择那20%的代码作为审查对象，可那些代码本身又很简单，所以最后也没看出什么需要改进的地方。这是我遇到的最严重的问题，毕竟如果代码都是以两个人写的，那就完全不需要什么正式的审查，结对检查或者代码阅读或许都更有效率一些。

最后是对发现问题的跟进和反馈不及时。三次代码审查以后，以发现了20多处问题。可除了我负责的部分，其他代码基本上没有什么改动。由于功能开发还在进行，那些代码随时都会被改动，那么原来记录的行号什么的就都没用了。