Code Review Practice

date
Aug 1, 2021
slug
code-review-practice
status
Published
tags
CodeReview
Code Spec
summary
type
Post

什么是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.
让谷歌的代码如此优秀的原因很简单:代码审查。在谷歌,任何产品、任何项目的代码都不会在没有审查的情况下进入代码库。
是一种文化,不是制度

为什么需要


工作中的痛点

  • 每个人代码风格不统一
  • 接口、类各种命名不统一
  • 深层逻辑问题,测试不容易发现
  • 吐槽「这TMD谁设计的,各种坑(可能是几个月前的自己)」

可以带给我们什么

  • 提升代码质量
  • 团队知识共享
  • 团队统一规范
  • 形成好的代码文化共识

Review什么


Google Review的原则

  • Design: Is the code well-designed and appropriate for your system?
  • Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?
  • Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
  • Tests: Does the code have correct and well-designed automated tests?
  • Naming: Did the developer choose clear names for variables, classes, methods, etc.?
  • Comments: Are the comments clear and useful?
  • Style: Does the code follow our style guides?
  • Documentation: Did the developer also update relevant documentation?

我们的Review原则

架构和设计

  • S.O.L.I.D
    • 单一职责原则(SRP)
    • 开放封闭原则(OCP)
    • 里氏替换原则(LSP)
    • 接口隔离原则(ISP)
    • 依赖倒置原则(DIP)
  • 行为是否统一
    • 缓存是否统一,错误处理是否统一,错误提示是否统一等等
    • 同一逻辑 / 同一行为有没有走同一Code Path。低质量程序的另一个特征是,同一行为 / 同一逻辑,因为出现在不同的地方或者被不同的方式触发,没有走同一Code Path 或者各处有一份copy的实现, 导致非常难以维护
  • DRY原则(Don't repeat your self)
  • 面向接口编程,而不是面向实现编程
  • 健壮性
    • 对Corner case有没有考虑完整,逻辑是否健壮?有没有潜在的bug?
    • 有没有内存泄漏?有没有循环依赖?(针对特定语言,比如Objective-C) ?有没有野指针?
    • 有没有考虑线程安全性, 数据访问的一致性
  • 错误处理
    • 有没有很好的Error Handling?比如网络出错,IO出错
  • 效率 / 性能
    • 对频繁消息和较大数据等耗时操作是否处理得当
    • 关键算法的时间复杂度多少?有没有可能有潜在的性能瓶颈

Style

  • 工程规范(工程结构,分层方式及命名等等)
  • Apollo配置规范
  • 命名规范(接口、类、方法名、变量名等)
  • 代码风格(括号、空格、换行、缩进等)
  • 注释规范(规定必要的注释)
  • 日志规范(合理的记录必要的日志)
  • DB SQL规范
  • URL规范

如何进行Code Review


团队前置准备

  • Git Branch Model
  • Git Message(能说明提交内容的)

何时触发

notion image
notion image

使用工具

  • Gitlab
  • Sonarqube

参考


【译】如何用人类的方式进行 Code Review(二)
这是我文章的后半部分,关于如何在 Code review 中进行良好的沟通,避免陷入一些潜在的陷阱。这里,我会着重于介绍一些技巧,让你的 Code review 能够顺利完成,避免磕磕碰碰。 在 第一篇文章 中,我介绍了很多基础的东西,所以我更推荐从那里开始读。当然如果你没有耐心,那么这里用一句话概括一些:一个好的代码评审者,不仅需要找出代码中的 bug,还需要提供认真负责的反馈来让团队伙伴得到能力上的提升。 我最糟糕的一次 Code review 经历,是和一个叫 Mallory 的前同事有关。她早我几年加入公司,但最近才转到我的团队来。 当我收到 Mallory 的第一份变更列表,里面的代码是很粗糙的。她之前完全没有写过 Python 代码,而且她的代码是基于一个我维护的笨重的老系统上开发的。 我很尽职地记录下了所有我找到的问题,一共有 59 个。按照其它 Review 文章的标准来看,我做得很不错。我找到了 如此多 的错误,所以我肯定是个优秀的评审者。 过了几天后,Mallory 给了我一份更新过的变更列表,已经针对我之前的 Review 修改过了。她修复了一些简单的问题,比如拼写错误、变量重命名等等,但她拒绝修改任何更高层次的问题,比如她的代码对于错误的输入会产生不确定的行为,还有她的一个函数嵌套了 6 层逻辑。她拒绝修改这些东西,轻蔑地解释说,这些东西不值得花工作时间去修复。 我看到这些,心情有些恼怒,所以又写了一轮新的评论。我的语气很专业,但是不可避免的有些火药味。"你能解释一下,为什么我们需要对于错误的输入会产生不确定的行为吗?"正如你所猜的那样,Mallory 的回复比之前更固执了。 一周后的星期二,Mallory 和我依然停留在第四轮相同的 Review 上。我前一天晚上提交了我的新一轮评论,但实际上我是故意拖了一天才提交的,因为当她读这些评论时,我不想跟她呆在一个屋子里。 整个早上,我一直觉得胃不舒服,因为我恐惧又要开始新一轮 Review。当我吃完午饭回来时,发现 Mallory 已经提交了新的代码,但她已经不在位置上了,我估计她也不想呆在我身边看着我审查这些更新。 我读了代码之后,我的心剧烈地跳动,因为真的被她惹怒了。我立刻开始奋力敲击我的键盘,指出她既没有按照我的要求作出修改,也没有用任何理由说服我批准这个变更列表。 我们就这样毅种循环(误)了整整三个星期,而代码几乎没怎么改动过。 幸运的是,我们团队里最高级别的工程师,Bob,帮我们打破了这个循环。他刚刚休完长假回来,惊讶地发现我们两个正在把 Code review
【译】如何用人类的方式进行 Code Review(二)
 

© 天行者YANG 2020 - 2022