代码评审(Code Review)

 通常在企业开发中,会定期`面对面`(face to face)对代码进行评审

 Code Review的意识

作为一个 `Developer`,不仅要`提交可工作的代码`(Deliver working code),更要`提交可维护的代码`(Deliver maintainable code)

 必要时进行重构,随着项目的迭代,在计划新增功能的同时,开发要主动计划重构的工作项

 开放的心态,虚心接受大家的`评审建议`(Review Comments)

 代码评审的方式

 开 Code Review 会议

 团队内部会整理 Check List

 团队内部成员交换代码

 找出可优化方案

 多问问题,例如:“这块儿是怎么工作的?”、“如果有XXX 情况,你这个怎么处理?”

 区分重点,优先抓住`设计`,`可读性`,`健壮性`等重点问题

 整理好的编码实践,用来作为 `Code Review` 的参考

 评审内容

 架构/设计

 单一职责原则

 这是经常被违背的原则。一个类只能干一个事情,一个方法最好也只干一件事情。比较常见的违背是`一个类既干UI的事情,又干逻辑的事情`,这个在低质量的客户端代码里很常见

  行为是否统一,例如:

 缓存是否统一

  错误处理是否统一

 错误提示是否统一

 弹出框是否统一

  ……

  代码污染

  代码有没有对其他模块强耦合

 重复代码

 开闭原则

  面向接口编程

 健壮性

 是否考虑线程安全

 数据访问是否一致性

 边界处理是否完整

  逻辑是否健壮

 是否有内存泄漏

 有没有循环依赖

  有没有野指针

  ……

 错误处理

 改动是不是对代码的提升

新的改动是打补丁,让代码质量继续恶化,还是对代码质量做了修复

效率/性能

关键算法的时间复杂度多少?有没有可能有潜在的性能瓶颈

客户端程序对频繁消息和较大数据等耗时操作是否处理得当

代码风格

 可读性

衡量可读性的可以有很好实践的标准,就是 Reviewer 能否非常容易的理解这个代码。如果不是,那意味着代码的可读性要进行改进

命名

命名对可读性非常重要

英语用词尽量准确一点,必要时可以查字典

函数长度/类长度

函数太长的不好阅读

类太长了,检查是否违反的 `单一职责` 原则

注释

 恰到好处的注释

参数个数

不要太多,一般不要超过 3 个

 Review Your Own Code First

每次提交前整体把自己的代码过一遍非常有帮助,尤其是看看有没有犯低级错误

你可能感兴趣的:(代码评审(Code Review))