在进行团队开发的时候，我们经常要对 pull request 进行代码审查，从而合并不同成员提交的代码。

我们在审查 pull request 的时候可能没有时间去查看代码的整体结构，而着重于被修改的部分。这时，我们可以从以下几个方面入手，检验代码的质量。

对于 Apex 代码的部分，本文参考了官方文库。

尽可能的对数据进行批处理

相比较其他编程语言，Apex 最大的特点是在云端执行。当一段代码在云端执行的时候，每次执行都是一个单独的批次。

如果我们在一段代码中需要处理数据，那么我们就要将数据批量的传入代码中，而不是每次处理一条。这样，大量的数据就可以在一个批次中一次处理完，提高执行效率。

简单的说，将函数的参数尽可能的定义为集合类型（列表 List、集合 Set），而不是一个 sObject 类型。

示例：

我们要实现一个将客户名称的后面添加 “Processed” 字样的功能，然后其他的类和功能（比如触发器、API）就可以调用它。

在实现的时候，我们将一个客户对象的列表作为参数传入函数。这样，Apex 代码在云端执行的时候就可以一次处理完多条数据。

public class BulkifyExampleClass {
    public static void BulkifyProcessFunction(List<Account> accounts) {
        for (Account acc : accounts) {
            acc.Name += ' Processed';
        }
    }
}

重复的逻辑

如果一段逻辑出现了两次或更多次，那么我们就必须将这段逻辑单独拎出来，建立一个函数，在不同的地方调用。

这是代码复用最基本的原则：不要重复（Don't Repeat Yourself）。

过度设计

在考虑代码的复用性时，开发者有可能走入另一个极端：过度设计代码的结构。

用户的需求总是会变动，所以我们在设计代码结构的时候需要考虑到未来的扩展性，会想象“如果需求扩展”，该如何更好地维护和修改。

这样考虑的结果有可能导致一些函数过于通用，其中包含了很多逻辑，处理了各种情况。但是在现实生活中，很多情况可能根本不会出现。

过多的“为未来准备”的逻辑会拖慢代码的运行效率。

比如：当一个函数包含了很多可选参数，而这些可选参数会根据不同的情况被使用或不用，那么函数中就会包含复杂的逻辑来判断各种情况。这些逻辑本身就会降低代码的维护性和运行效率。

冗长的函数

业务的流程有时候很复杂，从而导致开发者写出很多的逻辑来实现。如果将这些业务逻辑像流水账一样写在一个函数中，会使这个函数变得冗长。

这时，我们需要将复杂的逻辑拆分成独立的单元，每个单元封装在一个函数中，从而增加代码的可读性。

这种“模块化”思想是软件工程的基本理论之一。在设计项目的整体代码架构时，开发者一般不会犯错误。但是在工作强度很高的时候，开发者赶时间去完成一段复杂的业务逻辑，往往会写出冗长的函数，既难读又难维护。

永远不要相信用户的输入

在代码中，我们会将用户的输入作为参数进行进一步的处理，比如进行数据库的查询。在处理用户输入的时候，我们始终要坚持检查用户的输入，转义它们，永远不要直接使用它们。

SQL 注入、跨站脚本攻击等就是因为相信了用户的输入，从而将恶意的代码引入了原本的代码中，造成破坏。

循环中的逻辑

循环语句是最常用的逻辑语句之一。循环语句会将其内部的逻辑重复执行。

我们要保证在循环语句中的逻辑可以快速执行，而将需要大量时间的逻辑挪到循环外部。

一般来说，代码和数据库通讯需要花费很多时间。当我们有一组数据需要执行相同的逻辑并且存入数据库的时候，我们要保证循环语句中只包含逻辑，而不包含将数据存入数据库的操作。当循环执行完以后，再通过一条语句将这一组数据一次性保存到数据库中。

在 Apex 中，我们可以使用 DML 语句或者 Database 类对数据进行处理。在需要进行这些操作的时候，我们要将它们放在循环语句的外面，从而避免重复的数据库读写操作。

比如：

for (Account acc : accounts) {
    acc.Name += ' Processed';
    update acc; // 多次更新操作，效率低
}

for (Account acc : accounts) {
    acc.Name += ' Processed';
}
update accounts; // 一次更新操作，效率高

避免重复的 SOQL 语句和循环

当我们需要对符合不同条件的同一类型数据进行不同的逻辑处理时，我们可以将它们使用一个 SOQL 语句读取出来，然后分别处理。这种情况多出现在触发器类中。

比如：对于所有新建的客户对象，我们有两个处理逻辑，分别基于它们的名字和雇员数量。

List<Account> bigAccounts = [SELECT Id, Name FROM Account WHERE numberOfEmployees > 500];
for (Account bigAccount : bigAccounts) {
    // 处理客户对象
}

List<Account> specialAccounts = [SELECT Id, Name FROM Account WHERE Name like '%special%'];
for (Account specialAccount : specialAccounts) {
    // 处理客户对象
}

这段代码使用了两次 SOQL 语句，也用了两个循环。我们将其可以优化如下：

List<Account> allAccounts = [SELECT Id, Name, numberOfEmployees FROM Account];
for (Account acc : allAccounts) {
    if (acc.numberOfEmployees > 500) {
        // 处理客户对象
    }
    if (acc.Name.contains('special')) {
        // 处理客户对象
    }
}

这样，将所有逻辑放在一个 SOQL 语句和一个循环中，可以提高代码执行的效率。

不合理的类关联

类和类之间应该保持尽可能少的联系。如果两个类之间的函数相互调用很多，那么可能这两个类本身就需要合并成一个。

尽量少的公用变量和函数

在一个类中，我们需要将公用的变量和函数控制在尽量少的数目。越少的公用部分代表着越少的外界修改权限。

类、函数、变量的命名

类、函数、变量等的命名需要简洁清晰，争取做到让别人不看具体的逻辑就能知道这部分的作用。

参数列表

如果一个函数需要很多参数作为输入，会导致参数列表过长，影响代码的整洁。这时可以定义一个对象，将需要传入的参数整合进对象中，一次传进函数。

比如，有一个函数只包含了创建“地址”的逻辑，它可以被其他代码调用。它拥有很多参数，代表了地址的各个组成部分：

public void createAddress(String streetName, String houseNumber, String postalCode, String city, String province, String country) { 
    //... 
}

在这种情况下，每次调用这个函数，开发者都要传入6个参数，很不方便，也容易出错。

我们可以定义一个“地址”的类 Address，将地址信息的组成部分作为类的成员。然后重写 createAddress 函数，让它只接受一个 Address 类型的参数：

public class Address {
    String streetName;
    String houseNumber;
    String postalCode;
    String city;
    String province;
    String country;

    // ...
}

// ...

public void createAddress(Address a) {
    // ...
}

这样，代码就变得整洁很多。当需要调用 createAddress 函数时，开发者会自己创建合适的 Address 对象，作为参数传入。

注释风格

有一个笑话，说的是“程序员最讨厌两件事：没有注释的别人的代码、为自己的代码写注释”。写注释的最大的误区是没有表达清楚为什么写这段注释，而只是为了注释而注释。

注释是给接手的人看的，不是给机器看的，所以写注释的时候最重要的是讲明为什么写下这段代码，而不是代码本身包含的逻辑。

在为类、函数等组件命名的时候，这些名字大多已经概括了它们的作用和逻辑，其他人接手这段代码时很容易就可以弄清楚。但是很多时候接手的人并不清楚当时写下这段代码的原因，从而不知道这段代码和项目其他部分的联系。在进行修改或者重构的时候牵一发而动全身，造成无法预料的错误。