[原]代码审查审什么

代码审查审什么


看着很多人做代码审查重点审格式和命名，制定的代码规范也主要偏重代码格式和命名，我真想骂一句操蛋，这真是浪费时间又解决不了问题。此篇文章就是骂完操蛋后奋笔快速敲下来的，有不妥之处请大家谅解。


一、目的：为啥要花费时间要搞人工代码审查？


1、有些问题是工具检查不出来的，需要人工审查
2、有些问题是不希望花大代价来发现、或者上线后才知道


二、重心：代码审查的重心是什么


1、函数
2、集成
3、性能
4、安全


三、详解：函数审查


函数审查的重点是：
1、函数的输入输出。这本质就是接口。接口不能根据需求变化变来变去，所以接口设计/修改需要非常小心，需要专人来分析识别接口、专人来设计维护接口。以不变应万变，很难


2、函数的分支/嵌套。很多开发人员不会分析分解业务场景、业务逻辑，不是缠绕在一起就是把场景逻辑拆的一地零件组合不起来。所以要拆要合都非常难。因此业务场景业务逻辑多复杂，函数就有多长。因此函数分支/嵌套也是需要多审查多指导如何合理划分。函数的分支/嵌套会影响代码未来的阅读学习难度/维护修改难度，这都是成本/效率/质量的关键根源。


3、函数的异常和日志。异常结构如何设计、日志结构如何设计、如何记录、如何上报给用户，这都是讲究。烂的异常截获、报告、记录，都让用户莫名其妙、让技术人员难以根据信息快速找到问题根源。甚至有人搞异常处理都把业务逻辑都搞乱了。


函数是一个开发人员的基本功、基本要求，所以重点审查函数该怎么合理设计，这是代码设计的一部分。想想你的程序员做代码设计吗？


四、详解：集成


集成的关键是自我封闭、有限联接、明确联接。


所以要关注：
1、功能点源代码包之间的互相调用、依赖
2、模块包之间的互相调用、依赖
3、模块组包之间的互相调用、依赖
4、系统包之间的互相调用、依赖
5、系统组包之间的互相调用、依赖


要做到最少联接，要减少双向依赖。


刚才讲到的都是横向关联，咱们还要关注纵向关联：
1、UI表现层、数据传输层、服务层、业务逻辑层、逻辑-数据服务层、数据处理层、数据存储层


尽量做到最小联接、单向调用、物理独立部署、明确接口。


让数据层集成尽量通过数据复制分发平台做、让业务逻辑层集成通过EBS做、让UI层集成通过统一门户做，这样功能之间的联接就少的多


五、详解：性能


性能分为：架构性能、功能性能、编码性能、部署性能、运维持续优化性能。我们这里做代码审查主要做编码性能审查，架构性能保证由架构师和架构评审来决定。


编码性能主要分为：UI渲染层性能、业务逻辑层性能、数据存储层性能


UI层编码性能关键看存取、增删、遍历DOM节点；业务逻辑层性能关注事务长度/复杂度、事务锁；数据存储层关注SQL/索引。


六、详解：安全


安全也是分为：架构安全、功能安全、编码安全、部署安全、运维持续监控优化安全。我们主要关注编码安全。


编码安全也主要分为：UI层安全、业务逻辑层安全、数据存储层安全。


UI层安全关键是：sesion使用、cookies使用、插件使用、Form/Field输入信息防注入、URL串防注入、防止客户端脚本编码中泄漏后台数据结构/数据账号的代码。


业务逻辑层安全关键是：业务场景逻辑漏洞、角色权限漏洞


数据存储层安全关键是：敏感数据是否明文存储、关键数据变更留痕日志审计


七、谁来做代码审查？


1、代码审查、代码质量提升，首要就是开发leader的职责，应该由开发Leader率领来做
2、可以人盯人、层层盯。高级开发审初级的代码、开发leader审中级的代码。这样隔层来审，会让技能提高很快。最怕就是让棋篓子审其他棋篓子的代码，两个人的技能都是半斤八两，越审越烂

八、应该审哪些代码？

按重要性来分：

1、复杂度高的想重写重构的代码

2、经常出BUG的代码

按人来分：

1、重点审新进的人写的代码，让新进的人形成良好的代码习惯，不要让代码池子受污染

九、怎么做代码审查？

方式1：开发Leader率领大家开代码分析例会，挑出想重构或经常出BUG的代码，然后一个个函数让大家挑问题，然后把改进建议记录下来，以后整理出代码规范让大家遵守和审查。这个方式适合刚刚开展代码审查的研发团队

方式2：高级开发审初级的代码、开发leader审中级的代码，标出具体代码具体问题。这个方式适合已经大家每个人都会做代码审查的研发团队

十、审完了该干啥？

1、有隐含BUG的就改隐含BUG，这是首要

2、对于未来隐患的，如可扩展、可维护的，在下一阶段包含进重构需求范围内

3、把代码审查建议完善增补到代码规范、代码审查制度中，供以后代码编写与审查时遵守