看着很多人做代码审查重点审格式和命名，制定的代码规范也主要偏重代码格式和命名，我真想骂一句操蛋，这真是浪费时间又解决不了问题。此篇文章就是骂完操蛋后奋笔快速敲下来的，有不妥之处请大家谅解。一、目的：为啥要花费时间要搞人工代码审查？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、把代码审查建议完善增补到代码规范、代码审查制度中，供以后代码编写与审查时遵守
如果大家觉得好，请关注阿朱的微信公众号【erpweixin】 阿朱出品 必属精品
想看历史精彩文章，请点击我的公众账号头像后，点击里面的查看历史消息菜单
