前言

测试作为整个项目中的一环，在项目流程中起着不可或缺的作用。部分团队是缺少项目管理角色的，这个时候，测试对项目流程的推进、项目质量的保证显得尤为重要。好的测试，能在整个项目流程中以QA角度做好项目管理和及时的风险预警，让项目如期上线且保障质量。业界一直强调测试前置，那么测试在项目中，如何根据项目情况做前置工作推进项目流程，让大家都开心工作呢？本文以自己所在的项目组为例讲述项目流程中的一些事，希望可以与大家一同探讨~

一、QA在项目中扮演的角色

【why】明确目标是什么：明确做这个项目的目标是什么，可适当根据目标对需求实现、项目质量、研发提测时间点等做一些调节。

【when】项目的deadline：考虑项目组的特殊性，我们需要知道项目需要什么时候上线，明确项目deadline，根据时间节点制定合适的测试计划

【what】各阶段我们需要做什么：可以重点关注项目流程中，QA参与与输出的环节。有输入才会有输出，所以输出的环节往往是需要QA花费时间去思考的地方。

【how】遇到风险点时怎么做：测试阶段，除了QA环节的风险点需要及时暴露和push外，这个阶段研发和产品也在做一些工作。在项目流程管理中，作为最下游的参与者，需要关注这些风险点，及时暴露和push解决。

【who】QA、RD、PM

二、我们面临的挑战

2.1挑战点

1.发版频率在排名第二，2021全年发版71次，相当于每周都有一个版本在进行迭代，快速迭代的节奏， 对人效和团队协同效率要求高。

2.整个2021年，研发人均bug数为123个，bug较多， 提测质量不高。为了不拉长项目周期， 保障较短的bugfix时间非常关键，同时要考虑如何提高提测质量。

3.整个2021年，测试人均提bug量最多，在项目节奏紧张的情况下，发现和提bug的效率必须提升。

2.2关于提测质量

针对上述挑战的内容，我们可以看到提测质量上，我们存在不足之处。我们之前做过提高冒烟用例比例、冒烟交叉执行、时间预估增加冒烟时间等尝试，最后发现收获的效果有限。主要原因如下：

1. 多方合作、项目有固定deadline：由于项目特殊性，部分需求是多方合作的模式且有固定的deadline，就需要项目尽快上线，在对项目效率有极高要求的情况下，我们允许带一些层级深的bug上线，针对上线情况做hot
   fix。
2. 项目节奏紧张，需快速迭代更新：现有研发团队是串行的节奏，能持续高效迭代，为保证项目节奏的稳定性，避免出现因一个项目周期拉的过长导致节奏紊乱，我们接受分步提测的形式，就有可能出现冒烟功能不完整的情况，导致提测质量不如预期。

基于以上原因，我们可以看到在质量与效率之间需要做一定的选择时，需要向项目效率倾斜，所以我们既然无法更好地改变提测质量，那就去改变我们能改变的。

三、面对这些挑战，QA可以做什么

QA可以做什么让整个迭代周期变短，在bug很多的情况下还能快速迭代且线上问题较少呢？先来看下我们的项目流程：

从整个项目流程上看，可能与很多团队如出一辙。在流程上，QA作为下游的一个部分，可以看到QA参与输出的内容其实有很多，这些部分就是我们可以尝试去改变提升的点。
那么我们从这些输出内容看下，面对上述挑战，QA都做了哪些改变以及还有哪些困境。

3.1项目排期计划

项目排期计划模板：

【when】项目排期一般是需求评审完后，根据需求拆分需求模块和开发模块。
排期计划中，QA的工作：熟悉需求，拆分需求模块，制定测试计划
QA同学加入进模块拆解，能更好的了解需求，拆分的开发模块也能更快的知道当有bug时，bug是属于哪个端的，提给哪位对应的开发。
根据各模块的提测时间和大致开发周期，QA同学也能制定对应的测试计划。

【what】– QA具体需要做什么

1. 协助开发拆分功能模块，确保模块都有对应的开发负责人
2. 确认项目deadline、开发总预计时间和提测时间

3.2测试计划制定

项目测试计划模板：

【when】测试计划一般在项目排期给出后1天内提供，后续根据排期动态调整

测试计划中，QA的工作：根据需求预估时间和人力，明确测试环境与策略，制定合理的测试计划，预估风险

【what】– QA具体需要做什么

1.拆分功能模块，模块明确好对应的测试。（包含用例编写安排、一、二轮测试安排和兼容测试安排）

2.预估好项目的总体测试时间和各轮次的测试时间

3.一轮接近尾声时，与开发明确好上预发时间；二轮接近尾声时，与开发明确好上online环境的时间

4.如有数据配置项，二轮测试开始前与产品明确好配置所需内容和完成时间节点

以上1、2两点尽早提供，其余可在对应时间点给出。当然，如遇到需求变更、人力变更等需要及时提出和调整。　

【how】– 具体怎么做

根据开发排期，动态制定和调整合理测试的计划。

• 根据提测时间，决定用例执行顺序与分配：
  如下图拆分的测试计划，后台配置（星火）与用户端提测时间不一致，结合两个提测时间点，我们利用用户端提测前的时间，先执行后台配置的用例，这样即使是分步提测，我们也能确保每次提测时测试资源能跟上。
  

• 根据功能制定测试轮次
  对于主干功能：需要多次执行测试用例，一般制定三轮的测试，一轮在测试环境，二轮预发环境，三轮线上环境
  对于对内的、不影响用户使用的功能：制定一轮测试，在测试环境测一轮。比如星火等配置后台是给运营使用的，做一轮测试，上预发后产品走查验证+配置内容即可
  活动类的功能：依据活动的复杂程度和使用频次，制定测试轮次。比如新年活动，是一次性的活动且活动时间紧，评估后我们在预发做了一轮测试就上线了，上线质量也一样较好。具体测试流程：活动类测试流程尝试
  

• 按照模块、用例量与难度划分，制定每人每天用例执行目标
  一轮测试模块划分根据用例编写与熟悉度划分

• 实行交叉测试，避免因不熟悉导致遗漏或效率降低
  二轮进测试进行交叉，利用TC平台的任务指派，也可以清楚看到组员的任务数量与完成情况。

如下图，测试计划的拆解与人员分配，细致划分到每人每日的工作目标，且各模块的分配会进行交叉，一轮测试人员发现用例不完善或测试不方便的地方也即使提供了文档以便二轮人员尽快上手测试。

【小结】：我们可以看到，调整测试计划的4种方式，主要目的都是通过这些办法去更高效地去完成测试任务，保障项目如期上线；更完善、全面地去发现bug，提升项目质量。测试计划的合理调整分配，是面对项目过程中各种挑战的有效方式之一。

3.3jira定制化流程

1. 定制化的jira项目流程：
   

版本发布管理三部曲：

• jira版本发布管理：从产品建立版本开始，到最终复盘，整个流程和数据统计都体现在jira看板中，方便统一管理
• 项目进度自动同步：如下，项目组成员能很清晰的知道当前项目进度，且版本进度每天都会自动在大群同步；完结的项目，也会根据项目情况自动同步复盘信息
  

【小结】：

1.定制化的流程，让流程更加统一规范和智能化。

2.关键信息的及时同步，能减少每日站会、信息同步会等重复会议，节约了时间。
各团队之前的协作更加顺畅，那团队协同效率和人效也就自然而然能进一步提高。

2. QA高效提bug、研发快速修bug秘诀：

2021Q1 效率工具的需求收集提效讨论中，提bug流程的优化建议一一实现了，每个人提bug 的速度大幅提升，主要汇总如下：

• bug区分问题类型 —— 使bug分类更精准，能更好地分析数据，push对应人员
• bug状态展示优化 —— 各状态一目了然，更快找到需要处理的bug
• bug描述预置版本、步骤、设备等信息 —— 减少重复内容输入，提bug效率更高

• jira移动版接入使用 —— 附件内容更方便上传，bug描述更准确，减少因无法复现、描述不清等原因带来的重复沟通成本
  

• bug流程新增：一轮漏测、fix bug引入选项、bug描述不清的状态 —— 当然这些指标目的不是为了追究是开发或是测试的责任，是为了分析bug，总结原因，从中找出不足的地方（比如用例设计不完善、开发修复bug未自测等问题），大家共同进步，提升项目质量，从而让项目进行更流畅与高效。

• 自动提醒开发QAfix和验收bug：—— 精准找到需要处理bug，处理效率大大提升
  项目流程复盘中，我们约定p1bug当天需要fix，p2bug原则上fix周期不超过T+1天，验收不超过T+2天。如下图，就是根据形成的规范自动提醒研发、测试的内容：
  
  

【小结】：

1.即使是预置的一些提bug信息和界面优化，也让测试更“优雅”地工作，提bug和验bug也更有劲儿了。

2.T+1修复周期的约定与消息推送，给了研发一个心里预期，正如我们根据项目情况调整测试策略一般，研发也根据我们给的预期调整了工作模式，从而使研发fix bug周期保障到最短，高效且有质量地修复了bug。　

工作流程的调整与满满预期的加持，让整个团队的工作效率极大提高。　　　　　　　　　　　　

3.4测试报告

1. 测试日报

【when】一般项目提测后，需要每日下班前发送日报

【what】– QA具体需要做什么

汇总其他QA的进度，根据项目情况发送日报or周报。
日报中风险项一环节可根据项目情况修改，同步计划、提醒事项等都可以写入。
push开发fix bug：p1 修复周期不超过T+1天，bug数量较多时，可根据测试情况适当催开发修改（比如一轮测试接近尾声，还有很多服务端前端bug，就需要催一下了）

【how】– 具体怎么做

在galaxy平台工具上，实现了日报自动生成工具，每日可自动生成日报内容，方便大家看进度，且日报中还有当前bug状态和链接，研发也能更快找到自己的bug。
日报一键生成效果如下：

【小结】：

日报的自动生成，节省了测试每日汇总进度的时间，更是直接大幅减少了关键信息的沟通同步成本，是人效和团队协同效率提升的又一次加成buff。

2. 质量报告（测试报告）

【when】项目上线后，对项目进行总结梳理

【how】– 具体怎么做
结合jira的使用流程，可一键生成测试报告并同步质量平台。

生成的测试报告示例：

3.5项目复盘

【when】项目上线后的一周内，小型项目如有必要可合并组织

【why】复盘的目的：针对项目中不足之处，共同讨论对策，争取下次做的更好

【what】– QA具体需要做什么

1.数据文档准备：形式其实不做限制，需要的数据、文档等准备好即可，也可以与开发轮流组织。

2.会议上形成的todo list需要进行跟进处理

【how】– 具体怎么做

复盘例子：

复盘提效jira看板：如下图 — ps：催bug或者发日报的时候也可以使用，比较清晰

【小结】：定期做项目复盘，让团队意识到我们当前存在的问题，推进项目流程一次比一次做的更好。

【不足】：
当然，在复盘过程中，各团队虽然达成一些共识共同改进，也遇到了一些列问题。

问题一：项目节奏已经很紧张的情况下，大家可能都在赶项目进度，没有余力去做复盘总结工作，追求效率从而忽视了质量。

问题二：复盘形成的todolist也没时间去跟进，导致复盘的总结内容最后不了了之，复盘失去意义。

问题三：一些复盘改进点，往往由于各种特殊原因而不能按规定执行 。

基于以上原因，复盘收获的效果是比较有限的，也是我们今后需要探讨与改进的一个命题。

四、项目风险

4.1风险评估

项目流程中，我们关注各个阶段需要做什么事的同时也会做项目管理与把控，关注项目风险，守住deadline。

风险可以分为两类：质量风险和进度风险

举个例子：
用例编写的时间不够，影响测试时间和上线时间，我们称之为进度风险；而用例编写时，编写用例人员不熟该功能，用例覆盖不足，我们可以称之为质量风险。

这里我们主要关注的是项目进度，所以着重关注进度风险一项。进度风险，就是在项目进度中出现的风险从而影响了整个项目的时间点。

在测试计中，我们设计了风险一栏放于第一位，目的就是让QA在项目流程中，及时从测试角度去观测和记录风险。

比如：

4.2风险对策

面对风险出现时，需要case by case讨论。在进度风险出现时，首要原则就是及时暴露风险、寻找方法去尽可能降低风险。

项目组很多项目因与其他部门配合，有固定deadline并且允许有部分已知问题带上线，那么我们一般从测试开发角度去商议的解决办法如下：

以上方案如果还不能守住deadline，就要考虑项目延期。

结语

上述内容是作者所在项目组结合已有的测试流程，针对项目遇到的挑战进行流程推进以及推进后的总结介绍。
鉴于不同项目组的特殊和差异性，文中提到的方法和手段可能只是冰山一角，不一定完全适用各类项目。根据项目情况做前置工作推进项目流程，其实是一个很大的命题，不同项目组有时存在的问题也不尽相同，测试在项目流程中还能做哪些更 nice 的事，还是需要靠大家在现有情况下去进行探索和总结。也欢迎大家留言与我们交流讨论~

摘要

计算机基础的同学估计对管道这个词都不陌生了，尤其是在Linux系统当中，管道操作符已经被广泛的使用，并给我们的变成带来了极大的便利。前端领域比较注明的脚手架“gulp”也是以其管道操作著称。
今天我们就来一步步抽丝剥茧，看看在前端领域的“管道数据流”要如何设计。

一、前言

有计算机基础的同学估计对管道这个词都不陌生了，尤其是在Linux系统当中，管道操作符已经被广泛的使用，并给我们的变成带来了极大的便利。管道操作通常分为单向管道和双向管道，当数据从上一节管道流向下一节管道时，我们的数据将会被这节管道进行一定的加工处理，处理完毕后送往下一节管道，依次类推，这样就可以对一些原始的数据在不断的管道流动中进行不断的加工，最后得到我们想要的目标数据。
在我们日常编程开发过程中，也可以尝试使用管道数据的概念，对我们的程序架构进行一定的优化，让我们程序的数据流动更加清晰明了，并可以让我们像是流水线一样，每个管道专门负责各自的工作对数据源进行一次粗加工，达到职责分明与程序解耦的目的。

二、程序设计

现在我们使用Typescript实现一个基础的管道类的设计，我们今天使用的管道是单向管道。

2.1 Pipe-转接头

顾名思义，转接头就是需要将不同的多节管道连接在一起成为一整条管道的连接口，通过这个连接头，我们可以控制数据的流向，让数据流向他真正该去的的地方。
首先，我们来设计一下我们的转接头的类型结构：

type Pipeline = {
  /**
   * 将多节管道链接起来
   * e.g.
   * const app = new BaseApp();
   * app.pipe(new TestApp1()).pipe(new TestApp2()).pipe(new TestApp3()).pipe(new Output()).pipe(new End())
   * @param _next
   */
  pipe(_next: Pipeline): Pipeline;
};

上述代码描述了一个支持管道数据的类需要有怎样的一个转接头，在程序设计中，我们的转接头其实就是一个函数，用于将多节管道相互链接。
从上面的代码大家可以看出，为了程序的高复用，我们选择对管道中传输的数据类型进行泛型化，这样，我们再具体实现某一个程序时，便可更加灵活的使用其中类型，例如：

// 时间类型的管道
type DatePipeline = Pipeline
// 数组类型的管道
type ArrayPipeLine = Pipeline
// 自定义数据类型的管道
type CustomPipeLine = Pipeline<{name: string, age: number}>

除此之外，我们这个函数的传入参数和返回值也是有讲究的，从上面的代码可以看出，我们接收一个管道类型的数据，又返回一个管道类型的数据。其中，参数中传入的便是下一节管道，这样，我们就把两节管道连接到了一起。之所以要返回一个管道类型的数据，是为了让我们使用时可以链式调用，更符合管道数据的设计理念，如：

const app = new AppWithPipleline();
app.pipe(new WorkerPipeline1())
   .pipe(new WorkerPipeline2())
   .pipe(new WorkerPipeline3())
   .pipe(new WorkerPipeline4())

也就是说，我们返回的，其实也是下一节管道的引用。

2.2 Push-水泵

有了转接头之后，我们还需要一个“水泵”将我们的数据源源不断地推送到不同的管道，最终到达目标点。

type Pipeline = {
  /**
   * 实现该方法可以将数据通过管道一层层传递下去
   * @param data
   */
  push(data: T[]): Promise;
  /**
   * 将多节管道链接起来
   * e.g.
   * const app = new BaseApp();
   * app.pipe(new TestApp1()).pipe(new TestApp2()).pipe(new TestApp3()).pipe(new Output()).pipe(new End())
   * @param _next
   */
  pipe(_next: Pipeline): Pipeline;
};

为了适应更多场景，我们设计这个水泵接受一个T[]类型的数组，在第一节管道当中，当我们拿到了初始的数据源时，我们就可以利用这个水泵（方法）将数据推送出去，让后面的每一个加工车间处理数据。

2.3 resolveData – 加工车间

当我们的数据被推送到某一节管道时，会有一个加工车间对推送过来的数据根据各自不同的工序进行粗加工。
注意：我们每一个加工车间应该尽可能保证职责分离，每个加工车间负责一部分的工作，对数据进行一次粗加工，而不是把所有的工作都放到一个加工车间当中，否则就失去了管道数据的意义。

type Pipeline = {
  /**
   * 实现该方法可以将数据通过管道一层层传递下去
   * @param data
   */
  push(data: T[]): Promise;
  /**
   * 将多节管道链接起来
   * e.g.
   * const app = new BaseApp();
   * app.pipe(new TestApp1()).pipe(new TestApp2()).pipe(new TestApp3()).pipe(new Output()).pipe(new End())
   * @param _next
   */
  pipe(_next: Pipeline): Pipeline;
  /**
   * 用于接受从上一节管道传递下来的数据，可进行加工后传递到下一节管道
   * @param data
   */
  resolveData(data: T[]): T[] | Promise;
};

​加工车间依旧是接收一个T[]类型的数据数组，拿到这个数据后，按照各自的工序对数据进行加工处理，加工好之后，重新放回流水线的传送带上（返回值），送往下一节管道的加工车间继续加工。

三、具体实现

上面我们只是定义了一个管道应该有的最基本的行为，只有具备以上行为能力的类我们才认为它是一节合格的管道。那么，接下来，我们就来看看一个管道类需要如何实现。

3.1 基础管道模型类

class BaseApp
 implements Pipeline
 {
  constructor(data?: P[]) {
    data && this.push(data);
  }
  /**
   * 仅内部使用，下一节管道的引用
   */
  protected next: Pipeline
 | undefined;
  /**
   * 接受到数据后，使用 resolveData 处理获得新书局后，将新数据推送到下一节管道
   * @param data
   */
  async push(data: P[]): Promise {
    data = await this.resolveData(data);
    this.next?.push(data);
  }
  /**
   * 链接管道
   * 让 pipe 的返回值始终是下一节管道的引用，这样就可以链式调用
   * @param _next
   * @returns
   */
  pipe(_next: Pipeline
): Pipeline
 {
    this.next = _next;
    return _next;
  }
  /**
   * 数据处理，返回最新的数据对象
   * @param data
   * @returns
   */
  resolveData(data: P[]): P[] | Promise {
    return data;
  }
}

我们定义了一个实现了Pipleline接口的基础类，用来描述所有管道的样子，我们所有的管道都需要继承到这个基础类。
在构造函数中，我们接受一个可选参，这个参数代表我们的初始数据源，只有第一节管道需要传入这个参数为整个管道注入初始数据，我们拿到这个初始数据后，会使用水泵(push)将这个数据推送出去。

3.2 管道统一数据对象

通常在程序实现时，我们会定义一个统一的数据对象作为管道中流动的数据，这样更好维护与管理。

type PipeLineData = {
    datasource: {
        userInfo: {
            firstName: string;
            lastName: string;
            age: number,
        }
    }
}

3.3 第一节管道

由于第一节管道之前没有任何管道了，我们想要让数据流动起来，就需要在第一节管道处使用水泵给予数据一个初始动能，让他可以流动起来，因此，第一节管道的实现会与其他管道略有不同。

export class PipelineWorker1 extends BaseApp {
  constructor(data: T[]) {
    super(data);
  }
}

第一节管道主要的功能就是接受原始数据源，并使用水泵将数据发送出去，所以实现起来比较简单，只需要继承我们的基类BaseApp，并将初始数据源提交给基类，基类再用水泵将数据推送出去即可。

3.4 其他管道

其他管道每个管道都会有一个数据处理车间，用来处理流向当前管道的数据，因此我们还需要重写基类的resolveData方法。

export class PipelineWorker2 extends BaseApp {
  constructor() {
    super();
  }
  resolveData(data: PipeLineData[]): PipeLineData[] | Promise {
    // 在这里我们可以对数据进行一些特定的处理
    // 注意我们尽可能在传入的 data 上进行操作，保持引用
    data.forEach(item => {
        item.userInfo.name = ${item.userInfo.firstName} · ${item.userInfo.lastName}
    });
    // 最后，我们再调用基类的 resolveData 方法，把处理好的数据传进去，
    // 这样就完成了一道工序的加工了
    return super.resolveData(data);
  }
}

export class PipelineWorker3 extends BaseApp {
  constructor() {
    super();
  }
  resolveData(data: PipeLineData[]): PipeLineData[] | Promise {
    // 在这里我们可以对数据进行一些特定的处理
    // 注意我们尽可能在传入的 data 上进行操作，保持引用
    data.forEach(item => {
        item.userInfo.age += 10;
    });
    // 最后，我们再调用基类的 resolveData 方法，把处理好的数据传进去，
    // 这样就完成了一道工序的加工了
    return super.resolveData(data);
  }
}

export class Output extends BaseApp {
  constructor() {
    super();
  }
  resolveData(data: PipeLineData[]): PipeLineData[] | Promise {
    // 在这里我们可以对数据进行一些特定的处理
    // 注意我们尽可能在传入的 data 上进行操作，保持引用
    console.log(data);
    // 最后，我们再调用基类的 resolveData 方法，把处理好的数据传进去，
    // 这样就完成了一道工序的加工了
    return super.resolveData(data);
  }
}
// 我们还可以利用管道组装灵活的特性开发出各种各样的插件，可随时插拔
export class Plugin1 extends BaseApp {
  constructor() {
    super();
  }
  resolveData(data: PipeLineData[]): PipeLineData[] | Promise {
    // 在这里我们可以对数据进行一些特定的处理
    // 注意我们尽可能在传入的 data 上进行操作，保持引用
    console.log("这是一个插件");
    // 最后，我们再调用基类的 resolveData 方法，把处理好的数据传进去，
    // 这样就完成了一道工序的加工了
    return super.resolveData(data);
  }
}

3.5 组装管道

上面我们已经将每一节管道都准备好了，现在要把他们组装起来，投入使用了。

const datasource = {
    userInfo: {
        firstName: "kiner",
        lastName: "tang",
        age: 18
    }
};
const app = new PipelineWorker1(datasource);
// 管道可以随意组合
app.pipe(new Output())
   .pipe(new PipelineWorker2())
   .pipe(new Output())
   .pipe(new PipelineWorker3())
   .pipe(new Output())
   .pipe(new Plugin1());

四、结语

至此，我们就已经完成了一个管道架构的设计了。是不是觉得，使用了管道数据之后，我们的整个程序代码的数据流向更加清晰，每个模块之前的分工更加分明，模块与模块之前的项目配合更加灵活了呢？
使用管道设计，还能让我们可以额外扩充一个插件库，用户可以随意定制符合各个业务场景的插件，让我们的程序的扩展性变得极强。

摘要
本文介绍了基于 XMLHttpRequest、Promise、async/await 等三种异步网络请求的写法，其中async/await 写法允许我们以类似于同步的方式编写异步程序，摆脱繁琐的回调函数。

一、背景

为了应对越来越多的测试需求，减少重复性的工作，有道智能硬件测试组基于 electron 开发了一系列测试提效工具。

electron 的编程语言是js，因为大家都不是专业的前端，对js不太熟悉，在编写程序时踩了不少坑。尤其是js中的事件和网络请求，这些涉及到异步编程的地方很容易出错。

随着工具的快速开发迭代，代码中出现了越来越多的嵌套的回调函数，工具崩溃的几率也越来越大。为了解决这些问题，我们用 async/await 对这些回调函数进行了重构，使得代码量下降，代码的可读性和可理解性都有了大幅度提高。

本文介绍了基于 XMLHttpRequest、Promise、async/await 等三种异步网络请求的写法，其中 async/await 写法允许我们以类似于同步的方式编写异步程序，摆脱繁琐的回调函数。

二、前言

在js中如果只是发起单个网络请求还不算复杂，用fetch、axios或者直接用XMLHttpRequest就能满足要求。

但若是多个请求按顺序拉取数据那写起来就很麻烦了，因为js中的网络请求都是异步的，想要顺序执行最常见写法就是在回调函数中发起下一个请求，如下面这些代码：

const requestOptions = {
    method: 'GET',
    redirect: 'follow'
};

fetch('https://xxx.yyy.com/api/zzz/', requestOptions)
    .then(response => response.json())
    .then(data => {
        fetch('https://xxx.yyy.com/api/aaa/'+data.id, requestOptions)
            .then(response => response.json())
            .then(data => {
                console.log(data)
            })
            .catch(error => console.error('error', error));
    })
    .catch(error => console.error('error', error));

假设我需要经过两步获取一个数据，如从https://xxx.yyy.com/api/zzz/获取一个数据对象data，通过data.id得到我要获取数据的序号，之后再发一次请求得到想要的数据。

用回调函数的方式就类似于上面这样，太繁琐了，而且容易出错，并且一旦逻辑复杂就不好改啦。

接下来梳理一下js的几种网络请求方式，摆脱回调地狱，希望对遇到类似问题的小伙伴有所帮助。

（一）XMLHttpRequest

首先是XMLHttpRequest，初学前端时大名鼎鼎的Ajax主要指的就是它。通过XMLHttpRequest对象创建网络请求的套路如下：

// 假设访问http://localhost:3000/user返回json对象{"name":"YouDao"}
const xhr = new XMLHttpRequest();
const url = 'http://localhost:3000/user'

xhr.onreadystatechange = function(){
  if (this.readyState == 4 && this.status == 200){
    const json=JSON.parse(xhr.responseText)
    const name=json.name
    console.log(name)
  }
}
xhr.open('GET',url)
xhr.send()

这段代码首先创建一个XMLHttpRequest对象xhr，然后给xhr.onreadystatechange添加readystatechange事件的回调函数，之后xhr.open(‘GET’,url)初始化请求，最后由xhr.send()发送请求。

请求发送后，程序会继续执行不会阻塞，这也是异步调用的好处。当浏览器收到响应时就会进入xhr.onreadystatechange的回调函数中去。在整个请求过程中，xhr.onreadystatechange会触发四次，每次readyState都会自增，从1一直到4，只有到了最后阶段也就是readyState为4时才能得到最终的响应数据。到达第四阶段后还要根据status判断响应的状态码是否正常，通常响应码为200说明请求没有遇到问题。这段代码最终会在控制台上会打出YouDao。

可以看出，通过XMLHttpRequest处理请求的话，首先要针对每个请求创建一个XMLHttpRequest对象，然后还要对每个对象绑定readystatechange事件的回调函数，若是多个请求串起来，想想就很麻烦。

（二）Promise

Promise是在 ECMAScript 2015 引入的，如果一个事件依赖于另一个事件返回的结果，那么使用回调会使代码变得很复杂。Promise对象提供了检查操作失败或成功的一种模式。如果成功，则会返回另一个Promise。这使得回调的书写更加规范。

通过Promise处理的套路如下：

const promise = new Promise((resolve,reject)=>{
  let condition = true;
  if (condition) {
    resolve("ok")
  } else {
    reject("failed")
  }
}).then( msg => console.log(msg))
  .catch( err => console.error(err))
  .finally( _ =>console.log("finally"))

上面这段代码把整个处理过程串起来了，首先创建一个Promise对象，它的构造器接收一个函数，函数的第一个参数是没出错时要执行的函数resolve，第二个参数是出错后要执行的函数reject。

resolve指执行成功后then里面的回调函数，reject指执行失败后catch里执行的回调函数。最后的finally是不论成功失败都会执行的，可以用来做一些收尾清理工作。

基于Promise的网络请求可以用axios库或浏览器自带的fetch实现。

axios库创建请求的套路如下：

import axios from 'axios'
const url = 'http://xxx.yyy.com/'
axios.get(url)
  .then(data => console.log(data))
  .catch(err => console.error(err))

我比较喜欢用fetch，fetch是用来代替XMLHttpRequest的浏览器API，它不需要导库，fetch创建请求的方式和axios类似，在开头已经展示过了就不重复写了。

虽然Promise把回调函数的编写方式简化了一些，但还是没有摆脱回调地狱，多个请求串起来的话就会像我开头写的那样，在then里面创建新的Promise，最终变成Promise地狱。

（三）async/await

async/await是在 ECMAScript 2017 引入的，可以简化Promise的写法，使得代码中的异步函数调用可以按顺序执行，易于理解。

下面就用开头的那个例子说明吧：

直接用fetch获取数据：

const requestOptions = {
    method: 'GET',
    redirect: 'follow'
};

fetch('https://xxx.yyy.com/api/zzz/', requestOptions)
    .then(response => response.json())
    .then(data => {
        fetch('https://xxx.yyy.com/api/aaa/'+data.id, requestOptions)
            .then(response => response.json())
            .then(data => {
                console.log(data)
            })
            .catch(error => console.error('error', error));
    })
    .catch(error => console.error('error', error));

用async/await改写后：

async function demo() {
​  const requestOptions = {
    method: 'GET',
    redirect: 'follow'
  };

  const response = await fetch('https://xxx.yyy.com/api/zzz/', requestOptions);
  const data = await response.json()
  const response1 = await fetch('https://xxx.yyy.com/api/aaa/'+data.id, requestOptions)
  const data1 = await response1.json()
  console.log(data1)
}

demo().catch(error => console.error('error',error))

改写后的代码是不是就很清楚了，没有那么多的then跟在后面了，这样如果有一连串的网络请求也不用怕了。

当async放在一个函数的声明前时，这个函数就是一个异步函数，调用该函数会返回一个Promise。
await用于等待一个Promise对象，它只能在异步函数中使用，await表达式会暂停当前异步函数的执行，等待 Promise 处理完成。

这样如果想让一连串的异步函数调用顺序执行，只要把被调用的这些函数放到一个用async修饰的函数中，调用前加上await就能让这些函数乖乖地顺序执行了。

结语
通过本文的梳理，相信你已经知道怎样避免回调地狱了。不过需要注意的是 Promise 是2015年加入语言规范的，而 async/await 是2017年才加入到语言规范的，如果你的项目比较老或者是必须要兼容老版本的浏览器（如IE6），那就需要用别的方式来解决回调地狱了。
对于 electron 只要你用的是近几年的版本都是支持的，electron 可以当成是 chromium 和 node.js 的结合体，特别适合用来写跨平台的工具类桌面应用程序。

JS的执行通常在单线程的环境中，遇到比较耗时的代码时，我们首先想到的是将任务分割，让它能够被中断，同时在其他任务到来的时候让出执行权，当其他任务执行后，再从之前中断的部分开始异步执行剩下的计算。所以关键是实现一套异步可中断的方案。那么我们将如何实现一种具备任务分割、异步执行、而且还能让出执行权的解决方案呢。React给出了相应的解决方案。

背景

React起源于 Facebook 的内部项目，用来架设 Instagram 的网站，并于 2013 年 5 月开源。该框架主要是一个用于构建用户界面的 JavaScript 库，主要用于构建 UI，对于当时双向数据绑定的前端世界来说，可谓是独树一帜。更独特的是，他在页面刷新中引入了局部刷新的机制。优点有很多，总结后react的主要特性如下：

1. 1 变换

框架认为 UI 只是把数据通过映射关系变换成另一种形式的数据。同样的输入必会有同样的输出。这恰好就是纯函数。

1.2 抽象

​实际场景中只需要用一个函数来实现复杂的 UI。重要的是，你需要把 UI 抽象成多个隐藏内部细节，还可以使用多个函数。通过在一个函数中调用另一个函数来实现复杂的用户界面，这就是抽象。

1.3 组合

为了达到可重用的特性，那么每一次组合，都只为他们创造一个新的容器是的。你还需要“其他抽象的容器再次进行组合。”就是将两个或者多个容器。不同的抽象合并为一个。

React 的核心价值会一直围绕着目标来做更新这件事，将更新和极致的用户体验结合起来，就是 React 团队一直在努力的事情。

变慢==>升级

随着应用越来越复杂，React15 架构中，dom diff 的时间超过 16.6ms，就可能会让页面卡顿。那么是哪些因素导致了react变慢，并且需要重构呢。

React15之前的版本中协调过程是同步的，也叫stack reconciler，又因为js的执行是单线程的，这就导致了在更新比较耗时的任务时，不能及时响应一些高优先级的任务，比如用户在处理耗时任务时输入页面会产生卡顿。页面卡顿的原因大概率由CPU占用过高产生，例如：渲染一个 React 组件时、发出网络请求时、执行函数时，都会占用 CPU，而CPU占用率过高就会产生阻塞的感觉。如何解决这个问题呢？

在我们在日常的开发中，JS的执行通常在单线程的环境中，遇到比较耗时的代码时，我们首先想到的是将任务分割，让它能够被中断，同时在其他任务到来的时候让出执行权，当其他任务执行后，再从之前中断的部分开始异步执行剩下的计算。所以关键是实现一套异步可中断的方案。

那么我们将如何实现一种具备任务分割、异步执行、而且还能让出执行权的解决方案呢。React给出了相应的解决方案。

2.1 任务划分

如何单线程的去执行分割后的任务，尤其是在react15中更新的过程是同步的，我们不能将其任意分割，所以react提供了一套数据结构让他既能够映射真实的dom也能作为分割的单元。这样就引出了我们的Fiber。

Fiber

Fiber是React的最小工作单元，在React中，一切皆为组件。HTML页面上，将多个DOM元素整合在一起可以称为一个组件，HTML标签可以是组件（HostComponent），普通的文本节点也可以是组件（HostText）。每一个组件就对应着一个fiber节点，许多fiber节点互相嵌套、关联，就组成了fiber树（为什么要使用链表结构：因为链表结构就是为了空间换时间，对于插入删除操作性能非常好），正如下面表示的Fiber树和DOM的关系一样：

Fiber树 DOM树

   div#root div#root
      | |
     div
      | / \
     div p a
    / ↖
   / ↖
  p ----> 
             |
             a

​一个 DOM 节点一定要着一个光纤节点节点，但一个光纤节点却非常有匹配的 DOM 节点节点。fiber作为工作单元的结构如下：

export type Fiber = {
  // 识别 fiber 类型的标签。
  tag: TypeOfWork,

  // child 的唯一标识符。
  key: null | string,

  // 元素的值。类型，用于在协调 child 的过程中保存身份。
  elementType: any,

  // 与该 fiber 相关的已解决的 function / class。
  type: any,

  // 与该 fiber 相关的当前状态。
  stateNode: any,

  // fiber 剩余的字段

  // 处理完这个问题后要返回的 fiber。
  // 这实际上就是 parent。
  // 它在概念上与堆栈帧的返回地址相同。
  return: Fiber | null,

  // 单链表树结构。
  child: Fiber | null,
  sibling: Fiber | null,
  index: number,

  // 最后一次用到连接该节点的引用。
  ref:
    | null
    | (((handle: mixed) => void) & { _stringRef: ?string, ... })
    | RefObject,

  // 进入处理这个 fiber 的数据。Arguments、Props。
  pendingProps: any, // 一旦我们重载标签，这种类型将更加具体。
  memoizedProps: any, // 用来创建输出的道具。

  // 一个状态更新和回调的队列。
  updateQueue: mixed,

  // 用来创建输出的状态
  memoizedState: any,

  mode: TypeOfMode,

  // Effect
  effectTag: SideEffectTag,
  subtreeTag: SubtreeTag,
  deletions: Array | null,

  // 单链表的快速到下一个 fiber 的副作用。
  nextEffect: Fiber | null,

  // 在这个子树中，第一个和最后一个有副作用的 fiber。
  // 这使得我们在复用这个 fiber 内所做的工作时，可以复用链表的一个片断。
  firstEffect: Fiber | null,
  lastEffect: Fiber | null,

  // 这是一个 fiber 的集合版本。每个被更新的 fiber 最终都是成对的。
  // 有些情况下，如果需要的话，我们可以清理这些成对的 fiber 来节省内存。
  alternate: Fiber | null,
};

了解完光纤的结构，那么光纤与光纤之间是如何并创建的链表树链接的呢。这里我们引出双缓冲机制

​在页面中被刷新用来渲染用户界面的树，被称为 current，它用来渲染当前用户界面。每当有更新时，Fiber 会建立一个 workInProgress 树（占用内存），它是由 React 元素中已经更新数据创建的。React 在这个 workInProgress 树上执行工作，并在下次渲染时使用这个更新的树。一旦这个 workInProgress 树被渲染到用户界面上，它就成为 current 树。

2.2 异步执行

那么fiber是如何被时间片异步执行的呢，提供一种思路，示例如下

let firstFiber
let nextFiber = firstFiber
let shouldYield = false
//firstFiber->firstChild->sibling
function performUnitOfWork(nextFiber){
  //...
  return nextFiber.next
}

function workLoop(deadline){
  while(nextFiber && !shouldYield){
          nextFiber = performUnitOfWork(nextFiber)
          shouldYield = deadline.timeReaming < 1
        }
  requestIdleCallback(workLoop)
}

requestIdleCallback(workLoop)

我们知道浏览器有一个api叫做requestIdleCallback，它可以在浏览器空闲的时候执行一些任务，我们用这个api执行react的更新，让高优先级的任务优先响应。对于requsetIdleCallback函数，下面是其原理。

​const temp = window.requestIdleCallback(callback[, options]);

对于普通的用户交互，上一帧的渲染到下一帧的渲染时间是属于系统空闲时间，Input输入，最快的单字符输入时间平均是33ms(通过持续按同一个键来触发)，相当于，上一帧到下一帧中间会存在大于16.4ms的空闲时间，就是说任何离散型交互，最小的系统空闲时间也有16.4ms，也就是说，离散型交互的最短帧长一般是33ms。

requestIdleCallback回调调用时机是在回调注册完成的上一帧渲染到下一帧渲染之间的空闲时间执行

callback 是要执行的回调函数，会传入 deadline 对象作为参数，deadline 包含：

timeRemaining：剩余时间，单位 ms，指的是该帧剩余时间。

didTimeout：布尔型，true 表示该帧里面没有执行回调，超时了。

options 里面有个重要参数 timeout，如果给定 timeout，那到了时间，不管有没有剩余时间，都会立刻执行回调
callback。

但事实是requestIdleCallback存在着浏览器的兼容性和触发不稳定的问题，所以我们需要用js实现一套时间片运行的机制，在react中这部分叫做scheduler。同时React团队也没有看到任何浏览器厂商在正向的推动requestIdleCallback的覆盖进程，所以React只能采用了偏hack的polyfill方案。

requestIdleCallback polyfill 方案( Scheduler )

上面说到requestIdleCallback存在的问题，在react中实现的时间片运行机制叫做scheduler，了解时间片的前提是了解通用场景下页面渲染的整个流程被称为一帧，浏览器渲染的一次完整流程大致为

执行JS--->计算Style--->构建布局模型(Layout)--->绘制图层样式(Paint)--->组合计算渲染呈现结果(Composite)

**帧的特性：**

帧的渲染过程是在JS执行流程之后或者说一个事件循环之后

帧的渲染过程是在一个独立的UI线程中处理的，还有GPU线程，用于绘制3D视图

帧的渲染与帧的更新呈现是异步的过程，因为屏幕刷新频率是一个固定的刷新频率，通常是60次/秒，就是说，渲染一帧的时间要尽可能的低于16.6毫秒，否则在一些高频次交互动作中是会出现丢帧卡顿的情况，这就是因为渲染帧和刷新频率不同步造成的
用户通常的交互动作，不要求一帧的渲染时间低于16.6毫秒，但也是需要遵循谷歌的RAIL模型的

那么Polyfill方案是如何在固定帧数内控制任务执行的呢，究其根本是借助requestAnimationFrame让一批扁平的任务恰好控制在一块一块的33ms这样的时间片内执行。

Lane

以上是我们的异步调度策略，但是仅有异步调度，我们怎么确定应该调度什么任务呢，哪些任务应该被先调度，哪些应该被后调度，这就引出了类似于微任务宏任务的Lane

有了异步调度，我们还需要细粒度的管理各个任务的优先级，让高优先级的任务优先执行，各个Fiber工作单元还能比较优先级，相同优先级的任务可以一起更新

关于lane的设计可以看下这篇：

https://github.com/facebook/react/pull/18796github.com/facebook/react/pull/18796

应用场景

有了上面所介绍的这样一套异步可中断分配机制，我们就可以实现batchUpdates批量更新等一系列操作：

更新fiber前

更新fiber后

以上除了cpu的瓶颈问题，还有一类问题是和副作用相关的问题，比如获取数据、文件操作等。不同设备性能和网络状况都不一样，react怎样去处理这些副作用，让我们在编码时最佳实践，运行应用时表现一致呢，这就需要react有分离副作用的能力。

设计serve computer

我们都写过获取数据的代码，在获取数据前展示loading，数据获取之后取消loading，假设我们的设备性能和网络状况都很好，数据很快就获取到了，那我们还有必要在一开始的时候展示loading吗？如何才能有更好的用户体验呢？

看下下面这个例子

function getSomething(id) {
  return fetch(${host}?id=${id}).then((res)=>{
    return res.param
  })
}

async function getTotalSomething(id1, id2) {
  const p1 = await getSomething(id1);
  const p2 = await getSomething(id2);

  return p1 + p2;
}

async function bundle(){
  await getTotalSomething('001', '002');
}

我们通常可以用async+await的方式获取数据，但是这会导致调用方法变成异步函数，这就是async的特性，无法分离副作用。

分离副作用，参考下面的代码

function useSomething(id) {
  useEffect((id)=>{
      fetch(${host}?id=${id}).then((res)=>{
       return res.param
      })
  }, [])
}

function TotalSomething({id1, id2}) {
  const p1 = useSomething(id1);
  const p2 = useSomething(id2);

  return 
}

这就是hook解耦副作用的能力。

解耦副作用在函数式编程的实践中非常常见，例如redux-saga，将副作用从saga中分离，自己不处理副作用，只负责发起请求。

function* fetchUser(action) {
   try {
      const user = yield call(Api.fetchUser, action.payload.userId);
      yield put({type: "USER_FETCH_SUCCEEDED", user: user});
   } catch (e) {
      yield put({type: "USER_FETCH_FAILED", message: e.message});
   }
}

严格意义上讲react是不支持Algebraic Effects的，但是借助fiber执行完更新之后交还执行权给浏览器，让浏览器决定后面怎么调度，Suspense也是这种概念的延伸。

const ProductResource = createResource(fetchProduct);

​const Proeuct = (props) => {
    const p = ProductResource.read( // 用同步的方式来编写异步代码!
          props.id
    );
  return 
{p.price}
;
}

function App() {
  return (
    

      Loading...
}>