关于代码审查（Code Review）的一些建议





关于代码审查（Code Review）的一些建议
1、代码审查目标
代码评审不是批斗会，不能以缺陷和错误来打击开发人员的积极性，评审的最终目标是提高系统质量及团队成员整体水平。

评审标准：代码编写是否规范、高效、简洁、健壮、可读性强。

2、代码审查内容
常规项
•代码能否正常工作？有没有实现预期的功能，逻辑是否正确？
•所有的代码是否简洁易懂？
•代码是否遵循既定的编码规范？包括但不局限于大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
•是否存在多余的或是多次重复的代码？
•代码是否尽可能的模块化了？
•是否有可以被替换的全局变量？
•是否有同一变量多次被赋予不同含义的值，容易使人理解错误？
•是否有被注释掉的代码？僵尸代码？
•循环是否设置了长度和正确的终止条件？
•是否有可以被库函数替代的代码？
•是否有可以删除的日志或调试代码？

安全项
•所有的数据输入是否都进行了安全检查（检测正确的类型，长度，格式和范围）并且进行了编码？
•在哪里使用了第三方依赖或服务，返回的错误是否被捕获？
•输出的值是否进行了检查并且编码？
•无效的参数值是否能够处理？
•防止未授权的访问
•防止漏洞注入
•避免硬编码敏感数据
•去掉注释中的死代码
•防止CSRF、XSS恶意攻击

3、代码审查关键点
•最近一次迭代开发的代码
•系统关键模块
•业务较复杂的模块
•缺陷率较高的模块

4、代码审查的好处
•提高软件整体质量，提升系统的可维护性。
•及早发现潜在缺陷与BUG，降低事故成本。
•促进团队内部知识共享，提高团队整体水平。
•评审过程对于评审人员来说，也是一种思路重构的过程，可以帮助更多的人理解系统。
•交叉审查代码，类似于结对编程，彼此都能熟悉对方模块业务，降低因人员流失的运营成本及风险。

后记：
代码审查建议每半月一次或一月一次，审查追求的是质量而不是数量。
不要过分要求程序员做代码审查。如果你强迫他们每天做一小时的代码审查，他们很快就会痛恨它，
把它当成一种无趣的任务。代码审查是针对代码，不是针对人。代码审查是一种学习，是表扬，是获得反馈，
是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。