码迷,mamicode.com
首页 > 其他好文 > 详细

代码审查要点简介

时间:2018-05-17 00:58:28      阅读:68      评论:0      收藏:0      [点我收藏+]

标签:function   开发者   语句   快速   作用   sele   tab   行数据   不用   

在进行团队开发的时候,我们经常要对 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 对象,作为参数传入。

注释风格

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

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

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

代码审查要点简介

标签:function   开发者   语句   快速   作用   sele   tab   行数据   不用   

原文地址:https://www.cnblogs.com/chengcheng0148/p/code_review_basic.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 mamicode.com 版权所有 京ICP备13008772号-2
迷上了代码!