代码复查（Code Review），又叫“代码审查”，其基本思想就是，在开发人员编写完自己的代码后，由其他人来复查他写的代码，从而有效地发现代码中存在的缺陷。代码复查的一个基本理论就是，当我们越早发现代码存在的缺陷，我们解决缺陷的代价就越低。
代码复查一般包括代码风格，常规缺陷，重大缺陷，程序语言级别缺陷和业务逻辑级别的缺陷，以及设计逻辑和思路的审查等等，甚至也要包括代码性能的考虑。代码复查的原则是正确性、可复用性、可扩展性、可维护性、可读性等等。
一提到代码走读，虽然我一次都没经历过，但是脑海里还是会想到一群人围着一个桌子，看着投影仪，作者不停的问：“大家看看这段代码有什么问题没”，大部分的人都还没反应过来这段代码是干什么的，50%的人就算没有看懂也会保持沉默，20%的人会要求作者把逻辑讲一遍，10%的人看懂了然后与作者交流，10%的人看看checklist再看看代码，另外10%的人一直盯着作者的眼睛，或者听他们讲话。（我可能就是最后那一种人）
我相信这种codereview效率很低，因为大家把理解代码是干什么的和发现问题放在一起同步进行，等待是同步的通病，我们不需要这种等待，在团队合作中也是如此。我们应该将这部分工作安排在线下进行，每个人按自己的思路理解程序的逻辑，然后找出问题，比如你的代码注释不够多，逻辑结构不够清晰，我们需要标注并且记录下来，这需要工具的支持。关于代码走读工具，可以参考【原】Eclipse Code Review（代码审查）工具介绍。
不管使用什么工具，它们都遵守一定的代码走读流程，下面是我脑海中的常规流程：
配置（Configuration）
在codereview之前，首先利用工具，建立review id，这个id就代表本次codereview，然后导入要评审的代码，接着给参与本次评审所有人员输入一个合法的ID，最后再输入一些额外的信息，比如项目名称，描述信息等等。然后评审发起人（代码作者、team leader或者PM）保存信息到配置库上。发邮件通知所有评审人员开始线下评审。
邮件的内容最好有以下几个部分：项目名称，review id，参与评审人员名单；简要介绍被评审代码的功能需求等等，帮助评审人员理解代码逻辑；要评审的代码范围，可以是文件列表；其他受影响的但没有在本次配置中加入的文件和模块；其他信息。
个人线下评审（Individual review）
首先update项目，得到相关配置信息，然后利用工具，得到个人评审的权限（这个权限是第一步review id创建人赋予的），接着根据邮件中的信息选择要评审的项目以及review id，然后开始正式阅读代码，理解代码逻辑，为代码添加评审意见，最好能具体到代码行级别，并且评审意见和代码相关联。当然，个人线下评审可以是多人同时进行的，比如Jupiter就支持这一点，它为每个评审人员都分配了不同的xml文件来保存评审意见，虽然很多配置库不支持多位用户对同一文件同时修改，但是因为是不同的文件，每位评审人员只关心属于自己的配置文件，这样就不存在这种问题了。
团队评审（Team review）
当所有个人线下评审完毕，就可以通知进行团队评审了。这一步就是前面描述的场景，但是这时的团队评审要轻松很多，因为大家已经各自明白了程序逻辑，也相应的填写了自己的评审意见。不用再去花费时间理解程序和发现问题了，大家把心思关注在已经发现的问题上。在团队评审时，之前所有进行个人线下评审意见都会暴露出来，这个时候的工作就是，针对每一个问题，讨论解决方法，然后通过工具保存至配置库。
代码修复（Rework）
这一步的参与人员只有源代码作者，根据第三步团队评审的意见，一个一个的把问题修复。各自修复完之后，通知所有的评审人员取出最新的配置数据，检查之前发现的各种问题是否修复正确，如果大家一致满意通过，就把本次review状态置为closed，如果未通过，就置为Re-opened。