Code Review最佳实践


关于Code Review的重要性,我相信好的工程师都能认识到。 参考 让Code Review称为一种习惯 和 从Code Review谈如何做技术

同时引用一下有人对Google Code Review的描述:

The biggest thing that makes Google’s code so good is simple: code review. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

这里主要Summary 一下 如何来做Code Review. 主要参考 Code Review Best Practices,同时加上了一些自己的理解。

Code Review 主要Revivew什么

Architecture/Design
  • 单一职责原则.
    • 这是经常被违背的原则。一个类只能干一个事情, 一个方法最好也只干一件事情。 比较常见的违背是一个类既干UI的事情,又干逻辑的事情, 这个在低质量的客户端代码里很常见。
  • 行为是否统一
    • 比如缓存是否统一,错误处理是否统一, 错误提示是否统一, 弹出框是否统一 等等。
    • 同一逻辑/同一行为 有没有走同一Code Path?低质量程序的另一个特征是,同一行为/同一逻辑,因为出现在不同的地方或者被不同的方式触发,没有走同一Code Path 或者各处有一份copy的实现, 导致非常难以维护。
  • 代码污染
    • 代码有没有对其他模块强耦合 ?
  • 重复代码
    • 主要看有没有把公用组件,可复用的代码,函数抽取出来。
  • Open/Closed 原则
    • 就是好不好扩展。 Open for extension, closed for modification.
  • 面向接口编程 和 不是 面向实现编程
    • 主要就是看有没有进行合适的抽象, 把一些行为抽象为接口。
  • 健壮性
    • 有没有考虑线程安全性, 数据访问的一致性
    • 对Corner case有没有考虑完整,逻辑是否健壮?有没有潜在的bug?
    • 有没有内存泄漏?有没有循环依赖?(针对特定语言,比如Objective-C) ?有没有野指针?
  • 错误处理
    • 有没有很好的Error Handling?比如网络出错,IO出错。
  • 改动是不是对代码的提升
    • 新的改动是打补丁,让代码质量继续恶化,还是对代码质量做了修复?
  • 效率/性能
    • 关键算法的时间复杂度多少?有没有可能有潜在的性能瓶颈。
    • 客户端程序 对频繁消息 和较大数据等耗时操作是否处理得当。

其中有一部分问题,比如一些设计原则, 可预见的效率问题, 开发模式一致性的问题 应该尽早在Design Review阶段解决。如果Design阶段没有解决,那至少在Code Review阶段也要把它找出来。

Style
  • 可读性
    • 衡量可读性的可以有很好实践的标准,就是Reviewer能否非常容易的理解这个代码。 如果不是,那意味着代码的可读性要进行改进。
  • 命名
    • 命名对可读性非常重要,我倾向于函数名/方法名长一点都没关系,必须是能自我阐述的。
    • 英语用词尽量准确一点(哪怕有时候需要借助Google Translate,是值得的)
  • 函数长度/类长度
    • 函数太长的不好阅读。 类太长了,比如超过了1000行,那你要看一下是否违反的“单一职责” 原则。
  • 注释
    • 恰到好处的注释。 但更多我看到比较差质量的工程的一个特点是缺少注释。
  • 参数个数
    • 不要太多, 一般不要超过3个。
Review Your Own Code First
  • 跟著名的橡皮鸭调试法(Rubber Duck Debugging)一样,每次提交前整体把自己的代码过一遍非常有帮助,尤其是看看有没有犯低级错误。
如何进行Code Review
  • 多问问题。多问 “这块儿是怎么工作的?” “如果有XXX case,你这个怎么处理?”
  • 每次提交的代码不要太多,最好不要超过1000行,否则review起来效率会非常低。
  • 当面讨论代替Comments。 大部分情况下小组内的同事是坐在一起的,face to face的 code review是非常有效的。
  • 区分重点,不要舍本逐末。 优先抓住 设计,可读性,健壮性等重点问题。
Code Review的意识
  • 作为一个Developer , 不仅要Deliver working code, 还要Deliver maintainable code.
  • 必要时进行重构,随着项目的迭代,在计划新增功能的同时,开发要主动计划重构的工作项。
  • 开放的心态,虚心接受大家的Review Comments。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Code Review度量是指对于软件代码进行评估和测量的一种方法。它有助于发现代码中的问题和漏洞,并提供改进和优化的方向。 首先,Code Review度量可以帮助评估代码的质量和可靠性。通过检查代码的结构、可读性、命名规范、注释等方面,我们可以确定代码是否符合最佳实践和标准。同时,我们也可以发现潜在的错误和漏洞,提前进行修复,从而提高代码的质量和可靠性。 其次,Code Review度量可以提供关于代码性能和效率的信息。通过代码审查,我们可以检查是否存在性能瓶颈、不必要的复杂度、低效的算法等问题。通过对这些问题的评估,我们可以提供优化和改进的建议,以提高代码的性能和效率。 此外,Code Review度量还可以帮助评估代码的可维护性和可扩展性。通过审查代码的结构、模块化和重用性等方面,我们可以确定代码是否易于维护和扩展。这样可以减少日后的代码维护成本,并提高代码的可扩展性,方便应对未来的需求变化。 总之,Code Review度量是一种对代码进行评估和测量的方法,可以帮助我们发现问题和提供改进的方向。通过这种方法,我们可以提高代码的质量、可靠性、性能、可维护性和可扩展性,从而提高软件的整体质量。 ### 回答2: Code Review度量是一种对代码质量和代码评审过程进行量化和衡量的方法。通过对代码的评审和分析,可以提高代码质量、减少错误和bug,以及提升团队的开发效率。 首先,Code Review度量可以通过代码质量指标来衡量代码的可读性、可维护性和可扩展性等方面。例如,可以通过检查代码规范的遵循程度、命名规范的合理性、模块化设计的清晰性等来评估代码的可读性。同时,还可以通过检查代码的注释完整性、错误处理机制的健全性、代码冗余度的高低等来评估代码的可维护性。此外,还可以通过检查代码的可测试性、是否符合设计原则等来评估代码的可扩展性。 其次,Code Review度量还可以衡量代码评审过程本身的质量和效率。例如,可以通过评估代码评审的覆盖率、评审人员的专业水平、评审意见的准确性和有效性等来评估评审过程的质量。同时,还可以通过评估评审的周期和占用的资源等来评估评审过程的效率。这些度量指标可以帮助团队掌握评审效果,及时发现问题和改进评审方法。 最后,Code Review度量还可以用于监控和改进团队的代码质量和评审过程。通过定期对代码质量和评审过程的度量,可以发现问题和瓶颈,并采取相应的措施进行改进。例如,可以通过度量评审结果中的缺陷率和遗漏率等指标来定期跟踪团队的代码质量变化,在发现问题时及时划定改进措施。同时,还可以通过评估评审过程的周期和资源占用情况来判断评审过程的效率,进而对评审流程进行优化。 总之,Code Review度量是提高代码质量和评审过程效果的重要手段,通过对代码和评审过程进行定量衡量和分析,可以及时发现问题并优化团队的开发流程。 ### 回答3: Code Review度量是指对代码审查过程进行量化和评估的方法。它帮助团队确定代码质量,发现潜在的缺陷和改进点。下面是一些常用的Code Review度量指标: 1. 代码覆盖率:代码覆盖率度量了被测试代码的执行路径是否被覆盖到。通过测量代码中被测试用例覆盖到的行数、分支、函数等,可以评估测试是否充分覆盖了代码。较高的代码覆盖率意味着更全面的测试,并有助于发现更多潜在的问题。 2. 缺陷密度:缺陷密度是指在代码中每行或每千行代码中存在的重要缺陷的数量。它可以帮助在不同的团队、项目或开发阶段之间进行比较,并衡量代码的质量。较低的缺陷密度意味着代码质量较高。 3. 代码复杂度:代码复杂度度量了代码的复杂性。通常使用诸如圈复杂度和类复杂度等指标来评估代码的可读性和可维护性。较低的复杂度意味着代码更易于理解和维护。 4. 代码规范遵循程度:代码规范遵循程度度量了代码是否符合团队或行业的编码规范。采用一致的编码风格和命名规范有助于提高代码可读性和可维护性。通过检查代码中规范规则的违反情况,可以评估代码的规范性。 5. 代码重复度:代码重复度度量了代码中的重复片段的数量和程度。重复的代码表明了设计上的问题,使得代码更难维护,并增加了引入缺陷的风险。降低代码重复度可以提高代码质量。 这些Code Review度量指标可以帮助团队全面评估代码质量、发现潜在问题和改进点,并进一步提高代码的可读性、可维护性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值