代码审（jiao）查（liu）的正确姿势代码

  

   正常来讲，做一个产品的难度是远远高于一个做技术的，涉及的问题很多很多，从最开始的市场调研开始，再到外观设计、硬件设计、固件设计及用于交互的软件，再到最后的测试、生产及维护。所以说能做出一个好的产品的人，往往都是一个协调管理能力非常强的人带着一群技术强人。

   今天就说说我心中的代码的交流吧。最近公司的一个产品被客户吐槽，心里挺难受的，写下这篇文章，以此来告诫自己：产品的质量是企业的生命，生命只有一次。

   一、代码审查的正确姿势

   在我认为是“审查”两个字毁了代码审查，人们往往会认为代码审查就是查找代码中的错误，各种挑刺，其实我的想法中，查找bug确实是代码审查中的一个功能，但是是最低级的一个功能，相互的吐槽挑刺往往会打击大家代码审查的积极性（请相信我，并不是每个程序员都希望大家挑他程序中的刺的），我希望的是：每个人写代码前，都知道了自己的代码写完之后会有整个团队的人来进行浏览分享，这样自然就会好好写了。主动的心态下写的代码往往比受迫的心态下写的代码要强的多，而且还分享了代码中的一些优点，大家的整个氛围都非常的融洽。
　　二、代码审查中的误区

误区一

　　代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。而通常会犯的一个错误，也是刚刚接触代码审查的新手容易犯的一个错误，即审阅者会判断这段代码是否按照自己思路来实现。

误区二

　　感觉一定要说点什么（才算是做了代码审查）。代码的作者花了很多的时间和精力来编写代码——你难道不应该说点什么吗？

　　三、代码审查中的部分清单

　　也就是说说在代码审查过程中，你需要注意哪些问题，把使用清单作为你的起点，针对特定的使用案例，你需要对其进行优化。一个比较棒的方式就是让你的团队记录下那些在代码审查过程中临时发现的问题，有了这些数据，你就能够确定你的团队常犯的错误，然后你就可以量身定制一个审查清单。确保你删除了那些没有出现过的错误。（你也可以保留那些出现概率很小，但是非常关键的项目，比如安全相关的问题）。当然，你还需要时时刻刻保持着清单的状态，不合适就需要更新，保正清单最适合你的团队。

常规项

• 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
• 所有的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽可能的模块化了？
• 是否有可以被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有可以被库函数替代的代码？
• 是否有可以删除的日志或调试代码？

安全

• 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查并且编码？
• 无效的参数值是否能够处理？

文档

• 是否有注释，并且描述了代码的意图？
• 所有的函数都有注释吗？
• 对非常规行为和边界情况处理是否有描述？
• 第三方库的使用和函数是否有文档？
• 数据结构和计量单位是否进行了解释？
• 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试

• 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
• 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
• 单元测试是否真正的测试了代码是否可以完成预期的功能？
• 是否检查了数组的“越界“错误？
• 是否有可以被已经存在的API所替代的测试代码？