代码审查的重要性
- 代码审查是熟悉软件架构，了解软件业务逻辑的好方法。学习代码是需要切入点的，一个上百万行代码的系统，从哪里开始着手？只能一个模块一个模块，一个组件一个组件的来熟悉，掌握。实现一个比较大的功能，你应该不会是唯一的开发人员，从系统架构师输出的系统设计，然后到各个团队中技术 Leader 输出的 component 级别的设计，到开始实现时，应该会把功能分为不同的模块有不同的开发人员协同实现。这是个学习的机会，不要只局限于自己这部分，为了了解这个大的功能，甚至和这个功能相关的其他已经实现的功能，你同样需要关注其他人的工作。有目的的看代码和漫无目的的浏览效果是不一样的，你已经对新功能有所了解，审查代码之前，你认为代码会怎么写，别人哪里和你想的不一样，旧功能和新功能是如何相互影响的等等，心里怀着问题，你的学习速度会更快，记得更加深刻。
- 代码审查是你提高自己的好方法。前提是 team 中有经验丰富的开发人员的存在。也就是大牛，不要错过让他看你代码的机会，不要害怕他会为你写的代码挑出一大堆问题，有人说你自己写的代码就像自己的孩子，见不得别人说半点不字，不要固执，要内心平静的，客观的去看待你所写的代码，发现并解决问题才能提高你自己。也不要错过去review大牛代码的机会，看看大牛写出来的代码是怎样的，你可以取其精华。
- 代码审查是需要功力的。网上有帖子说程序员的资深与否和工作年限没有必然联系，你是5年工作经验还是一个经验用了5年，这需要你去刻意练习，刚开始 reveiew 代码的时候你可能不习惯，也可能很痛苦，面对的一屏幕的代码不知如何下眼。但有一句话，如果你觉的内心很舒服，你就是在原地踏步。觉的痛苦说明你是在爬坡，刻意的去联系自己的大脑吧，今天你看一页代码可能用了一个小时，没有发现问题，但是坚持一个月甚至三个月之后，你看一眼就能够发现代码中的缺陷，恭喜你，你的功力加深了。
代码审查清单
常规项
- 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
- 所有的代码是否简单易懂？
- 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
- 是否存在多余的或是重复的代码？
- 代码是否尽可能的模块化了？
- 是否有可以被替换的全局变量？
- 是否有被注释掉的代码？
- 循环是否设置了长度和正确的终止条件？
- 是否有可以被库函数替代的代码？
- 是否有可以删除的日志或调试代码？
安全
- 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
- 在哪里使用了第三方工具，返回的错误是否被捕获？
- 输出的值是否进行了检查并且编码？
- 无效的参数值是否能够处理？
文档
- 是否有注释，并且描述了代码的意图？
- 所有的函数都有注释吗？
- 对非常规行为和边界情况处理是否有描述？
- 第三方库的使用和函数是否有文档？
- 数据结构和计量单位是否进行了解释？
- 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？
测试
- 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
- 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
- 单元测试是否真正的测试了代码是否可以完成预期的功能？
- 是否检查了数组的“越界“错误？
- 是否有可以被已经存在的API所替代的测试代码？
你同样需要把特定语言中有可能引起错误的问题添加到清单中。
优化你的清单
把使用清单作为你的起点，针对特定的使用案例，你需要对其进行优化。一个比较棒的方式就是让你的团队记录下那些在代码审查过程中临时发现的问题，有了这些数据，你就能够确定你的团队常犯的错误，然后你就可以量身定制一个审查清单。确保你删除了那些没有出现过的错误。（你也可以保留那些出现概率很小，但是非常关键的项目，比如安全相关的问题）。
得到认可并且保持更新
和你的团队分享这份清单并且让他们认同你清单的内容是个好主意。同样的，要定期检查你的清单，以确保各条目仍然是有意义的。
有了一个好的清单，除了可以提高你在代码审查过程中发现的缺陷个数，还可以帮助团队成员更好更快的进行代码审查。