一、背景

现在很流行谈测试左移，按我个人浅显的理解，测试同学的工作越往开发同学靠，越能体现 “左” 的概念，这里强调的理念是测试与开发工作保持高度统一，他们不分你我，互相有足够的信任和共同的目标，并发挥他们各自的价值。
Code Review，是测试左移的手段之一，通过 Review 代码，提前发现软件的潜在风险。

二、Review 代码前的准备

Review 代码前做充分的准备，如何开展？（供参考）

1、角色定位

设置自己是开发团队的新人，找一个开发哥当自己的导师，新人就会看很多开发文档，包括新人指南、业务介绍、技术文章等。这个过程要求我们熟悉业务、熟悉开发工作模式和流程

2、搭建开发环境

不管是客户端，服务端还是其他，都有开发对应的语言和代码编辑环境，如 AndroidStudio、IntelliJ IDEA、GoLand

3、熟悉代码编辑工具

查看 Git Log、切换分支、模糊查找、查找方法，高阶一些是编译和调试

4、熟悉语言的基础语法

这里说的熟悉，倒不是说熟悉到会写，我个人认为语法是帮助我们理清代码逻辑，关注代码整体是要做什么，有哪些可能的输入和输出、方法内部有哪些判断条件。这些了解基础的语法就能胜任

5、熟悉编码/语言规范

通用的编码/语言规范，提高代码可读性、可理解性，同时，也能约束开发遵循规范

三、Review 代码，Review 什么？

前期的所有准备都是值得的，也许过了一周、二周，甚至一个月，就算过了几个月也没关系，测试同学在为业务赋能的道路上一天天在进步，下面我结合自身经验，通过一些实际碰到过的案例，跟大家一起 Review 代码，如下：

1、Go 语言结构体定义错误

type AppPublisher struct {
    Name    string `json:"name"`
    Pkgname string `json:"pkgname"`
    Version string `json:"pkgname"`
}

Go 语言定义的结构体，可能我们并不熟悉这里的语法，但即使这样，也不影响我们发现它的错误，即第四行应定义为 Version string json:"version"，这么基础的定义为什么会犯错呢？这里可能跟开发编码的习惯有关，经常编码的人都知道，Command+D 复制当前行到下一行，所以这里猜测是复制了第三行代码到的第四行，导致忘记修改，其实这是开发经常出错的地方之一。

2、Java 随机函数取值范围

public void Solution(){
    int number = random.nextInt(0, 1)
    if(number == 1){
        ...处理业务逻辑...
    }
}

单看代码没看出什么问题，可能我们之前也不熟悉随机函数的用法，为此我们去度娘一把，nextInt(int k) 生成范围在 [0, k)（不包含 k）内的任意正整数，上面代码的 number 永远取不到 1，意味着下面的判断永远进不去，所以可以改为 random.nextInt(0, 2)。

3、初始化问题

public static String getOAID() {
    if(TextUtils.empty(Core.OAID)){
        String oaid = OaidManager.getOaid();
        if(!TextUtils.empty(oaid)){
            UniBundle.putOAID(oaid)
        } else {
            Core.OAID = UniBundle.getOAID();
        }
    }
    return Core.OAID;
}

看方法我们知道是要获取 oaid，但只要 OaidManager.getOaid() 有值，Core.OAID 永远都不会被赋值，正确的改法：

public static String getOAID() {
    if(TextUtils.empty(Core.OAID)){
        String oaid = OaidManager.getOaid();
        if(!TextUtils.empty(oaid)){
            UniBundle.putOAID(oaid)
        } 
        Core.OAID = UniBundle.getOAID();
    }
    return Core.OAID;
}

去掉 else，我们发现 Bug 往往在于多一行或少一行代码。

当然这样的案例有很多，以上是想告诉大家，Code Review 没有想象中这么困难，回到今日主题，
我在 Review 代码，我在 Review 什么？

1、明确涉及的接口及内容

我们很多需求逻辑需依赖各种配置平台，客户端通过网络请求获取配置，我们在 Review 代码过程中明确涉及的接口和内容，便于自己在测试时可以 Mock 配置测试，这里的价值在于降低一定沟通成本。同时，也能指导产品做相应的配置

2、明确涉及的数据/埋点上报

任何形式的数据/埋点上报，最为关键的是上报时机，其次才是上报内容。明确时机，明确内容

3、明确代码影响范围

这是老生常谈的内容，不管是开发或测试都最为关注的，也是难点、重点。我们测试常常询问开发，做新功能测试或回归测试时希望开发能给出明确的影响范围。有时候复杂的业务逻辑模糊了我们的方向，导致评估不准，但这里强调的是，多一个从测试评估的视角，而不是任凭开发圈定，测试能从代码去关注影响的范围，指导我们测试设计或回归相应的用例去覆盖影响，又或者这是不该被影响的业务逻辑

4、编码规范

编码规范也有一些内容，可以看看相关的技术文章。如命名规范、日志、代码格式等

5、业务逻辑

业务逻辑是我们关注的重中之重，我们的业务都建立在产品需求上，理清业务逻辑，并考虑是否合理。理清业务逻辑目的是指导我们设计相应的测试用例，考虑是否合理目的是否符合需求设计、交互设计、用户体验等

6、技术架构

给我们提出更高的要求，了解一些技术原理是必要的，透过现象看本质，才能明白数据走向、代码流程、框架流程等

四、结束语

以上是我结合自身经历的总结，实际工作环境可能比我们想象的更加复杂，每一个公司都有一套工作体系，我们其实在过程中不断摸索和成长，任重而道远，探讨各种技术经验，摸索适合自己或公司的工作方式。
我发现在这个过程中学到了很多知识，增强了开发的信任，当你在业务上的经验越来越丰富，在需求评审或技术评审阶段，能提出一些产品建议或技术建议，我想这也是测试在业务赋能上做出一定的贡献吧。
欢迎大家一起分享和交流。