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



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

1、代码审查目标

代码评审不是批斗会，不能以缺陷和错误来打击开发人员的积极性，评审的最终目标是提高系统质量及团队成员整体水平。

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

2、代码审查内容

常规项

•代码能否正常工作？有没有实现预期的功能，逻辑是否正确？

•所有的代码是否简洁易懂？

•代码是否遵循既定的编码规范？包括但不局限于大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。

•是否存在多余的或是多次重复的代码？

•代码是否尽可能的模块化了？

•是否有可以被替换的全局变量？

•是否有同一变量多次被赋予不同含义的值，容易使人理解错误？

•是否有被注释掉的代码？僵尸代码？

•循环是否设置了长度和正确的终止条件？

•是否有可以被库函数替代的代码？

•是否有可以删除的日志或调试代码？

安全项

•所有的数据输入是否都进行了安全检查（检测正确的类型，长度，格式和范围）并且进行了编码？

•在哪里使用了第三方依赖或服务，返回的错误是否被捕获？

•输出的值是否进行了检查并且编码？

•无效的参数值是否能够处理？

•防止未授权的访问

•防止漏洞注入

•避免硬编码敏感数据

•去掉注释中的死代码

•防止CSRF、XSS恶意攻击

3、代码审查关键点

•最近一次迭代开发的代码

•系统关键模块

•业务较复杂的模块

•缺陷率较高的模块

4、代码审查的好处

•提高软件整体质量，提升系统的可维护性。

•及早发现潜在缺陷与BUG，降低事故成本。

•促进团队内部知识共享，提高团队整体水平。

•评审过程对于评审人员来说，也是一种思路重构的过程，可以帮助更多的人理解系统。

•交叉审查代码，类似于结对编程，彼此都能熟悉对方模块业务，降低因人员流失的运营成本及风险。

后记：

代码审查建议每半月一次或一月一次，审查追求的是质量而不是数量。

不要过分要求程序员做代码审查。如果你强迫他们每天做一小时的代码审查，他们很快就会痛恨它，

把它当成一种无趣的任务。代码审查是针对代码，不是针对人。代码审查是一种学习，是表扬，是获得反馈，

是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。