准备​

开始前，我们需要准备本地开发环境。

1. NodeJS (>=14)；
2. Yarn (1.x)，安装方式：执行 npm install -g yarn；
3. Lerna，安装方式：执行 npm install -g lerna。

创建一个新的构件项目​

开发者可以按需创建自己的构件项目，每个项目中可以包含多个构件包，每个构件包又可以定义多个构件。

使用优维官方提供的 CLI 工具即可一键生成新的构件项目：

# 指定项目名称，例如 `my-repo`，将在当前目录创建一个子目录：
npx @next-core/create-next-repo my-repo

# 项目创建后，进入项目并安装 Node 模块。
cd my-repo && yarn

这个新生成的项目已经初始化提供了构建、测试、打包、代码静态检查等现代化的前端工程化配置，如果我们将项目托管在 GitHub 上，还可以开箱即用地使用包括持续集成和依赖更新等在内的自动化工作流。

创建一个新的构件包​

初始化的项目还没有任何构件包，我们先使用项目中内置的脚手架工具创建一个：

1. 运行 yarn yo；
2. 选择 a new package of bricks；
3. 输入构件包的名称，例如 my-bricks；
4. 然后，我们可以选择同时创建一个构件，本文为了演示我们先选择跳过。

新的构件包的代码就已经初始化完成，其中的各种工程配置文件可以按需自由调整。

创建一个新构件​

构件包有了，我们再创建一个新的构件：

1. 运行 yarn yo；
2. 选择 a new brick；
3. 输入构件的名称，例如 hello-world。

编写构件​

初始化的构件主要包含以下文件：

bricks/my-bricks/src/
  hello-world/           # 构件目录
    HelloWorld.spec.tsx  # React 组件单元测试
    HelloWorld.tsx       # React 组件代码
    index.spec.ts        # Custom Elements 单元测试
    index.spec.tsx       # Custom Elements 代码

这个构件已经可以使用，我们先启动开发版本的构建：

yarn start --scope @next-bricks/my-bricks

然后打开一个新的终端来启动开发服务：

yarn serve --local-bricks=my-bricks

接着就可以在我们的微应用中使用该构件了：

不过这个构件还只是一个空壳，我们接下来完善它。假设我们的需求是做一个按钮构件，简单做下修改：

import React from "react";
import { Button } from "antd";

export function HelloWorld(): React.ReactElement {
  return <Button>Hello World</Button>;
}

保存后，本地页面将立即更新：

属性​

我们再让构件支持一个“按钮类型”的属性：

import React from "react";
import { Button } from "antd";
import type { ButtonType } from "antd/lib/button";

export interface HelloWorldProps {
  buttonType?: ButtonType;
}

export function HelloWorld({
  buttonType,
}: HelloWorldProps): React.ReactElement {
  return <Button type={buttonType}>Hello World</Button>;
}

export class HelloWorldElement extends UpdatingElement {
  @property()
  buttonType: ButtonType;

  // ...

  protected _render(): void {
    if (this.isConnected) {
      ReactDOM.render(
        <BrickWrapper>
          <HelloWorld buttonType={this.buttonType} />
        </BrickWrapper>,
        this
      );
    }
  }
}

最后修改我们的应用编排，设置一个按钮类型：

brick: "my-bricks.hello-world"
properties:
  buttonType: "primary"

事件​

我们再为它添加一个点击事件：

export interface HelloWorldProps {
  buttonType?: ButtonType;
  onButtonClick(greeting?: string): void;
}

export function HelloWorld({
  buttonType,
  onButtonClick,
}: HelloWorldProps): React.ReactElement {
  const handleClick = useCallback(() => {
    onButtonClick("Hello World");
  }, [onButtonClick]);

  return (
    <Button type={buttonType} onClick={handleClick}>
      Hello World
    </Button>
  );
}

import { event, EventEmitter } from "@next-core/brick-kit";

export class HelloWorldElement extends UpdatingElement {
  // ...

  @event({ type: "button.click" })
  private _buttonClickEvent: EventEmitter<string>;

  private _handleButtonClick = (greeting: string): void => {
    this._buttonClickEvent.emit(greeting);
  };

  protected _render(): void {
    if (this.isConnected) {
      ReactDOM.render(
        <BrickWrapper>
          <HelloWorld
            buttonType={this.buttonType}
            onButtonClick={this._handleButtonClick}
          />
        </BrickWrapper>,
        this
      );
    }
  }
}

最后修改我们的应用编排，绑定一个按钮事件：

brick: "my-bricks.hello-world"
properties:
  buttonType: "primary"
events:
  button.click:
    action: "message.info"
    args:
      - "<% EVENT.detail %>"

点击该按钮，将弹出提示信息：

至此，我们完成了基本的构件能力的开发。

表达式​

表达式用于在编排中引用动态数据并进行简单的加工处理，可以在编排中随处使用，包括属性、事件、回调等等。

这里的表达式是 JavaScript 的表达式子集，对于有少量 Web 编程、或者 C/Java 编程经验的同学，上手都不会太难。

• 引用数据： <% CTX.saving %>
• 逻辑判断：<% CTX.saving ? "Saving..." : "Save" %>
• 数学运算: <% CTX.rate * 100 %>
• 字符串组装：<% `/project/${DATA.projectId}` %>
• 数据过滤：<% DATA.list.filter(item => item.active) %>

表达式还支持最新的 JavaScript 的语言特性，例如在 ES2020 中引入的可选链 Optional Chaining 和空值转换 Nullish Coalescing 语法：

• <% a?.b %>
• <% data.settings ?? defaultSettings %>

我们还在表达式中集成了 Lodash 和 Moment，对于有经验的开发者可以更得心应手的进行数据加工。此外还集成了 EasyMABuilder 官方提供的管道加工函数 brick-next-pipes，进行特定应用场景的数据加工。

• <% _.findLastIndex(list, "active") %>
• <% moment(date).format() %>
• <% PIPES.yamlStringify(input) %>

而为了使流式的、连续的数据加工可以更流畅的编写、并具有更好的可读性，我们加入了 JavaScript 目前还在提案阶段的 Pipeline Operator 的特性，并采用了其 minimal 草案。

• <% DATA.source |> JSON.parse |> PIPES.yamlStringify %>

另一方面，由于表达式的定位是处理简单的数据加工，除了不能使用 JS 语句类语法外，也限制了修改操作类的 JS 表达式语法，例如：赋值 a = 1、更新值 ++i、删除 delete a.b 等，同时也无法访问 DOM 对象。

微应用函数​

表达式使用简单的语法就可以完成常见的数据加工，而当面对更加复杂的数据处理的需求时，它就显得力不从心了，同时越复杂的逻辑越需要自动化测试来保障其健壮性和可维护性，这些都是表达式不具备的，因此，我们提供了微应用函数。

微应用函数直接在 Visual Builder 中相关的项目中编写，使用 JavaScript 或 TypeScript：

编写好的函数可以在该微应用的编排表达式中使用：<% FN.sayHello("World") %>。

微应用函数中可以使用上文表达式中提到的内置对象，例如 _、 moment、 PIPES 等。同时函数也可以使用同一个微应用下的其它函数。而无论使用 JavaScript 或 TypeScript ，函数编辑器都具有类型提示、自动补全、代码检查等能力，其体验向桌面 IDE 看齐。

对函数进行调试也非常简单，只需给出输入参数即可运行并查看返回结果：

微应用函数为解决复杂问题而生，虽然它直接在 Visual Builder 界面中编写，但仍需要手段来保障其质量、以及健壮性和可维护性。对此，我们提供了对函数进行单元测试的能力，并提供覆盖率统计。

与编写普通代码的单元测试不同，由于微应用函数专注于处理数据，不依赖副作用也不产生副作用，因此，我们的测试用例可以直接来自 Debug 的输入参数和输出结果。编写单元测试后，可以直接统计覆盖率，并在代码编辑器中给出未覆盖的代码部分的相关提示。

而在维护微应用函数时，修改代码并保存前，系统会自动运行单元测试，并对比测试预期结果，以便发现可能的问题：

至此，我们在低代码平台中获得了与专业代码媲美的编写代码的能力和体验，不过这些代码仅限于数据加工，它无法参与 UI 界面相关的工作，虽然 EasyMABuilder 提供了数百个开箱即用的构件，并提供了在微应用层面封装模板的能力，但对于 UI 界面，总有更个性化的场景和需求，对此，我们提供了用户编写新构件的能力，并提供配套的脚手架工具来方便用户更快捷的编写新构件，下一期我们将讲述《构件开发 Step by Step》。

而在低代码平台中，除了组织基本的 UI 界面结构外，还有一项重要的工作是维护和管理数据，特别是来自远端的异步数据、或者动态变更的状态数据。

对此，EasyMABuilder 提供了 Context 和 State 两种数据管理方式。

Context​

Context 在 EasyMABuilder 中用于管理全局的状态数据，在一个路由页面的生命周期中有效，其数据的初始化可以来自异步的远端请求的结果，也可以是静态声明的，这些数据可以在构件的属性或事件中引用，另一方面，它的值可以在页面的交互过程中按需动态更新，同时引用了相关数据的构件的属性也可以实时地获得更新。

例如，假设我们的页面需要一个显示主机列表的表格，该数据来自 CMDB 中的主机模型，我们可以在页面中声明一个 Context 数据：

然后在该页面的构件中就可以通过表达式来引用这些数据，例如赋值给表格的数据源属性：

另一方面，该状态数据可以在界面的交互过程中按需更新，例如通过某个特定事件来更改其状态数据。假设我们页面中有一个按钮，点击它将保存当前表单中的数据，同时我们希望点击它后立即禁用它，以防止连续点击发生，并在请求完成后恢复按钮状态。我们可以先定义一个 saving 的状态数据，并赋值给按钮的 disabled 属性：

注意我们使用了逗号表达式并前置了字符串 "track context"，它提示系统在相关数据变更时自动同步该属性。

接着，我们为按钮添加一个点击事件，并使用 context.replace 的动作，将 CTX.saving 更新为 true：

最后在请求完成的事件中设置回调动作，将 CTX.saving 重新设置为 false。

这样在我们的页面中，点击该按钮后，系统就会自动禁用它，直到请求完成再将按钮状态恢复。

除了上述基本的能力外，Context 还支持对请求返回的数据进行转换、请求的参数来自其他的 Context 等等。

State​

State 的能力和 Context 几乎完全一致，不同的是，Context 的作用域是整个页面、是全局的，而上一篇文章我们讲到了自定义模板，同一个模板在页面中可能有多个实例，如果直接使用 Context，则多个实例间的数据会互相影响，另外，使用全局的 Context 也会破坏模板的封装，削弱应用的可维护性，并带来潜在的问题。

因此 State 正是为了解决这个问题，它用于管理自定义模板内的数据，其作用域是模板的实例，多个模板实例之间的数据互相隔离，同时，在能力上完全与 Context 对等。State 与 Context 的区别有点像 JavaScript 中的 let/const 与 var。

上文中我们多次使用了「表达式」，和无代码平台不同，低代码平台为了能解决更丰富的应用场景、满足更个性化的需求，仍然离不开代码的编写，包括简单的逻辑计算和数据加工处理，而对于高阶开发者搭建更复杂的应用时，甚至需要不逊色于专业代码的开发体验，对此 EasyMABuilder 提供了对应的代码开发能力，本系列下一篇将讲述《数据处理：表达式和微应用函数》。

现代软件的开发追求最大化的可复用性，因为软件复用带来诸多好处：提升研发效率、降低研发成本、降低过程风险、增加可靠性、有利于标准化等。

构件就是 EasyMABuilder 中可复用的单元，通过组合现有的构件就可以搭建出完整的 Web 应用。

而随着应用规模的增长，开发者可能需要更上层的复用，即：将一套构件的组合封装成一个新的可复用的单元，并且希望它能像普通构件那样使用。例如我们可能需要一个显示趋势图的卡片，它由一个卡片构件及一个趋势图构件组成，我们希望将这个定制卡片能复用在多个页面中。

EasyMABuilder 对此提供了对构件组合的封装：自定义模板，以下我们简称为模板。

创建模板的界面与编排一个普通页面的界面完全一致，因为它们都是编排一套构件的组合。

不同的是，模板将内部的构件封装了起来，并且可以按需对外暴露属性、事件、方法和插槽，并将这些信息映射到内部的构件，这样，模板也有了普通构件的几大要素，因此它就可以像普通构件那样在各个地方复用。

例如，上文提到的趋势图卡片，我们可以先编排好模板的构件结构：

为了提升这个模板的可复用性，我们扩展一下它的能力，支持由外部传入卡片的标题和趋势图的数据源，进行一下属性映射的配置：

name: "tpl-trend-card"
properties:
  chartTitle:
    # 通过引用 ID `ref` 来查找内部构件
    ref: "my-card"
    refProperty: "cardTitle"
  dataSource:
    ref: "trend-chart"
    refProperty: "dataSource"

这样，我们的模板就有了两个属性 chartTitle 和 dataSource，设置或读取它们等同于读取内部构件的对应属性。

例如，我们可以在页面中同时编排两个趋势图卡片，分别显示 CPU 使用率和内存使用率：

path: "/my-page"
bricks:
  - brick: "tpl-trend-chart"
    properties:
      chartTitle: "CPU Usage"
      dataSource: '<% ... %>'
  - brick: "tpl-trend-chart"
    properties:
      chartTitle: "Memory Usage"
      dataSource: '<% ... %>'

事件、方法和插槽的映射方式与属性类似，其中，插槽的映射是系统在运行时通过模板的展开来实现的。

例如，假设我们为上面的模板再添加一个附加按钮的插槽 addon，映射到卡片构件的对应插槽上，然后我们为上面的 CPU 使用率卡片添加一个查看详细信息的附加按钮。

在模板被展开之前的页面 storyboard 中，构件树大约长这样：

展开后：

每个模板在运行时将被分别展开，其中的插槽下的子构件也会被移植到指定的内部构件的对应插槽上。例如上面的查看详情的附加按钮 view-detail 就被移植到了 CPU 使用率所在模板内部的卡片构件的 addon 插槽中。

自定义模板可以在每个应用内维护，也可以选择在多个应用之间连接共享，还可以单独打包并纳入平台的构件资源库中，就像普通的构件包一样。

由于模板就是构件组合的编排，因此可以轻易地将现有的页面编排的某个部分转换成模板，以便在别处复用，这样可以更加平滑地进行应用的迭代研发。

以上我们讲诉了自定义模板在兼容普通构件的基本能力的前提下，通过对构件组合的封装，在 EasyMABuilder 中提供了更上层的可复用单元，从而让开发者以更高的效率和更好的可靠性完成应用的编排。

在低代码平台中，除了组织基本的 UI 界面结构外，还有一项重要的工作是维护和管理数据，特别是来自远端的异步数据和动态变更的状态数据，本系列下一篇将讲述 EasyMABuilder 中的数据管理：Context 和 State。

其实，构件就是 HTML 元素。

但构件并不是 HTML 标准里已经定义好的那些元素（比如 body、div 等），而是开发者自定义的元素。这是一套 Web 标准技术 -- Web Components，它允许开发者使用 JavaScript API 来创建新的自定义的、可重用的、封装的 HTML 标签，并且可以像普通的 HTML 标签那样使用它们。这套技术可以追溯到 2011 年的 Fronteers Conference ^[1]，并且在 2016 年就开始逐渐获得主流浏览器的支持（Chrome 54+ ^[2], Firefox 63+）。

因此，EasyMABuilder 正是利用了原生的 Web 标准技术、结合组件化的开发思想，来搭建开发者熟悉的 Web 应用界面。

这些基于 Web Components 的构件，可以直接使用原生的 JS/CSS/HTML 来创建，或者结合你熟悉的任意主流第三方技术（例如 React/Vue/Angular）来创建^[3]。这使得 EasyMABuilder 的用户除了使用官方提供的构件资源外，也可以轻易地创建自己的个性化的构件。

Web Components 主要包含两项内容：Custom elements，和 Shadow DOM。

Custom elements 定义了一套 JavaScript API，允许开发者定义新的 HTML 标签以及它们的行为，或者加强已有的 HTML 标签，或者扩展其他开发者创作的组件。

而 Shadow DOM 则为元素提供了封装的能力，将样式、DOM 等行为都封装在元素内部，而不必担心它与外部的 ID 或者样式类名等产生冲突。

接下来，我们尝试结合上面的技术创建一个卡片元素。

首先，我们可以使用 <template> 来定义这个元素内部的结构：

<template id="tpl-my-card">
  <div class="card">
    <div class="title">My Card</div>
    <!-- 使用插槽来放置外部的子元素 -->
    <slot></slot>
  </div>
  <style>
    .card {
      border: 1px solid gray;
    }
    .title {
      border-bottom: 1px solid gray;
    }
  </style>
</template>

接着，我们可以创建这个元素：

class MyCard extends HTMLElement {
  constructor() {
    super();
    // 使用 Shadow DOM 封装内部结构。
    let shadowRoot = this.attachShadow({ mode: "open" });
    shadowRoot.appendChild(
      document.querySelector("#tpl-my-card").content.cloneNode(true)
    );
  }
}

window.customElements.define("my-card", MyCard);

然后我们就可以使用这个元素了：

<my-card>
  <p>Hello World!</p>
</my-card>

元素即构件，我们也可以在 EasyMABuilder 中使用它：

brick: "my-card"
slots:
  "":
    brick: "p"
    properties:
      textContent: "Hello World!"

开发者除了可以像上面那样从头开始编写一个元素/构件外，平台还提供了一些脚手架工具和 API 来帮助开发者更高效地编写构件：

import { UpdatingElement, property } from "@next-core/brick-kit";

class MyCard extends UpdatingElement {
  @property()
  cardTitle: string;

  @event({
    type: "card.collapse",
  })
  private _collapseEvent: EventEmitter;

  @method()
  collapse() {
    // ...
  }
}

关于 Web Components 更多的细节建议阅读谷歌 Web Fundamentals 系列的相关文章^[4]或 MDN 相关文档^[5]。

我们通过属性、方法和事件来灵活地定制每个构件的外观和行为，然后借助插槽、通过组合的方式来建立构件之间的层次，这和现代 Web 开发等组件化开发的思想相契合，是广受采纳和经受考验的最佳实践。

下一期我们将继续讲述对构件组合的封装：自定义模板。

其中主要包含以下三个基础部分：

• 微应用：即 Web 应用程序，由多个路由页面组成，每个页面由构件组装而来，构件如何组装定义在 Storyboard 中。Storyboard 是结构化数据，可以通过可视化工具编排出来，也可以直接用 YAML 或 JSON 配置。

• 构件：和前端开发者常说的「组件」类似，主要用于在页面上渲染特定的 UI 内容。开发者可以很容易地通过声明的方式使用构件，无需编程。

• EasyMABuilder Core：负责解析微应用的 storyboard，按照其定义加载路由并装载相应的构件，完成页面的渲染。

整个架构和乐高很像，用一块块积木、按特定的方式组合在一起，就可以拼搭出各式各样的东西出来。

EasyMABuilder 的基石就是这些积木--构件，正是一个个构件的组合搭建起了最终的应用。我们已经提供了数百个开箱即用的构件，包括功能完整的 UI 构件，以及包含特定业务属性的业务构件。同时开发者也可以开发自己的构件，以满足更加个性化的场景。

构件主要包含以下几大要素：

• 属性：构件的属性通常用于对该构件进行基本的参数设置。例如对于一个按钮构件，它可能会对外提供：按钮的文字内容、文字颜色等属性，这样应用在编排时可以按需设置属性，以实现不同的 UI 效果：

  brick: "my-button"
  properties:
    text: "Search"
    color: "blue"
  

  构件的属性可以是任意类型的数据，包括字符串、数字、布尔值、对象、数组等。

• 事件：构件可以在特定的用户交互等行为发生时触发特定的事件。例如对于一个表单构件，如果用户点击其中的提交按钮时，会发起一个表单提交的事件，并同时提供已填写的表单数据，那么开发者就可以按需配置提交后的动作：

  brick: "my-form"
  events:
    submit:
      action: "console.log"
  

  平台提供了多种形式的事件处理方式，包括页面跳转、更新构件属性或调用构件方法、发起远端请求、打印日志等等。

• 方法：构件可以对外提供特定的方法，以供别的地方按需调用。例如对于一个对话框构件，它会提供一个「打开对话框」的方法，可以在用户点击按钮时调用：

  brick: "my-button"
  events:
    click:
      target: "my-dialog"
      method: "open"
  

  注意，构件的方法可以接收任意的参数。

• 插槽：构件通过插槽可以让其他构件能以特定的方式容纳在该构件之内。例如表单构件可以提供一个插槽，允许其他的构件例如文本框、单选框等插入到表单中，同时表单构件还可以统一管理这些输入项的数据：

  brick: "my-form"
  slots:
    items:
      - brick: "my-input"
      - brick: "my-radio"
  

  

  插槽实际上定义了父子构件的关系，通过层层的构件组成一棵构件树，最终渲染成完整的页面。

这些要素使得各个构件可以灵活地适应不同的应用场景，开发者可以通过这些构件的组合编排出一个完整的微应用。

属性、事件、构件树，这些概念对于有了解 HTML 的同学会觉得有些熟悉：HTML 元素的属性和事件、以及由这些元素组成的 DOM 树。那么构件与 HTML 元素有什么关系呢，敬请期待本系列下一篇：《基于 WebComponents 的构件》。

该扩展程序可以为基于 Brick Next 框架下的页面对应的开发者工具中添加一个 “Bricks” 面板，其功能如下：

• 左上角选择 Bricks 时：
  • 查看页面当前渲染的构件树；
  • 构件内部使用的 useBrick 将被收集在 #internal 的标签中；
  • 已废弃或未定义等异常的构件将会在旁边显示对应的提示信息；
  • 当页面路由切换时，构件树会自动刷新，点击 🔄 可强制刷新构件树（用于路由未切换的构件更新等场景）；
  • 鼠标悬浮在一个构件上时，可以在页面上显示该构件的轮廓；
  • 点击选中一个构件时，右侧显示该构件当前的属性、绑定的事件等；
  • 选中构件后，可以点击右上角工具栏的 👁 唤起 Elements 面板并审查该构件对应的元素，或点击 </> 唤起 Sources 面板查看构件对应的源码；
• 左上角选择 Evaluations 时：
  • 监视当前页面发生的 Evaluate Placeholders 求值占位符的运算记录；
  • 可以输入 Expression 的关键字进行过滤；
  • 可以勾选 “String Wrap” 对字符串类型的值自动折行；
• 左上角选择 Transformations 时：
  • 监视当前页面发生的 Transform 数据转换的运算记录；
  • 可以勾选 “String Wrap” 对字符串类型的值自动折行；

本文尝试说明 Brick Next 架构下的依赖管理方法及其背后的原因。在阅读本文前，建议先阅读 npm 官方关于依赖声明的文档。

TL;DR​

• 在所有 Lerna 管理的项目中：
  • 开发设施依赖（包括测试、构建等工具）都声明在项目根目录的 package.json 的 devDependencies。
• 在由 create-next-repo 新建的仓库中：
  • 如果有某个包依赖了其它仓库（例如 brick-next）中的构件包、模板包，需要在仓库根目录中的 devDependencies 中额外声明它们。
• 在 @bricks/* 包中：
  • Custom Templates 依赖的其它构件包声明在 peerDependencies，版本号需要按 semver 正确声明；
  • 对 @next-dll/* 的依赖声明在 peerDependencies，并且版本号只需要填写 *；
  • 其它依赖声明在 devDependencies。
• 在 @micro-apps/* 或 @templates/* 包中：
  • @bricks/* 和 @templates/* 依赖声明在 peerDependencies；
  • 其他依赖声明在 devDependencies。
• 其他包（例如 @libs/*）中：
  • 对 @next-dll/* 的依赖声明在 peerDependencies，并且版本号只需要填写 *；
  • 其他依赖声明在 dependencies。
• 所有包不需要声明依赖 @next-core/bricks-dll 和 @next-core/bricks-types，它被声明在项目根目录中。
• DLL（包括 @next-core/bricks-dll 和 @next-dll/*）中已包含的依赖不需要再显示声明了。

Why​

我们先看不同类型的依赖有什么不同的表现：

• dependencies 会被递归安装，其它类型的依赖则不会。例如 A 依赖了 B，B 依赖了 C，那么在 A 包中执行 yarn 时，B C 都会被安装。
• peerDependencies 不会被自动安装。
• lerna version 发布版本时，会自动更新内部子包之间的 dependencies 及 devDependencies 的版本。

结合上述内容和我们的需求，就不难理解我们如何管理 Brick Next 的依赖了。

Q: 为什么 DLL 包含的依赖不需要再显示声明了？
A: dependencies 会被递归安装，冗余的声明一方面难以维护，另一方面容易造成版本差异导致问题。

Q: 为什么 @micro-apps/* 依赖的 @bricks/* 声明在 peerDependencies 并且还需要手动更新其依赖版本？
A: 小产品对构件库、模板库的依赖需要同步到 EasyOps 的包依赖关系中（package.conf.yaml），因此需要声明该依赖（我们的打包工具会扫描这些依赖生成一份 package.conf.yaml）。而我们期望构件库能保持兼容性，小产品对构件库的依赖版本不能始终跟随版本发布而更新，因此只有声明在 peerDependencies 中才不会被 Lerna 自动更新。也因此在小产品需要使用构件的新特性时，需要主动更新其依赖版本。

Q: 为什么 @bricks/* 的 Custom Templates 依赖的其它构件包要声明在 peerDependencies 中？ A: 如果 Custom Templates 中使用到了其它构件包的构件，那么这些依赖需要同步到 EasyOps 的包依赖关系中（package.conf.yaml），更多详情请参考上一条 Q/A。

Q: 为什么 @bricks/* 的其它依赖声明在 devDependencies？
A: @bricks/* 不会像 @libs/* 一样被 import 使用，我们只消费它生成的制品文件，因此它的依赖只在开发时有用。

Q: 为什么 @bricks/* 需要主动声明对 @next-dll/* 的依赖并放在 peerDependencies 中？ A: @bricks/* 被加载前需要按需加载用到的 @next-dll/*，所以需要有地方声明它们；另一方面，我们不希望 @next-dll/* 更新时也触发 @bricks/* 更新，所以放置到 peerDependencies 中。

Q: 为什么 @libs/* 的普通依赖都声明在 dependencies？ A: @libs/* 和我们日常使用的普通第三方库一样，会被 import 并在打包时整体编译，因此需要它的依赖及其依赖的依赖都被正确地安装在 node_modules 中。

Q: 为什么在由 create-next-repo 新建的仓库中，需要在仓库根目录中的 devDependencies 中额外声明构件包、模板包的依赖？ A: 因为 @micro-apps/* 对构件包、模板包的依赖基于这些包声明的构件列表、模板列表，所以需要在仓库中安装这些包才能完成相关校验和检查。而之前的 brick-next 大仓库模式下这些包都在本地，所以不需要声明及安装。

架构​

EasyCore是一个单体的架构，数据完整的存储在一个机器上，采用Raft协议将数据复制到多台机器，通过多副本的机制确保数据的安全和可靠。Client通过grpc协议与EasyCore进行通信，提供了图API供Client操作图数据库。

采用这种架构的好处是：

• 组件单一，降低部署和维护的门槛，理论上可以秒级启动一个图数据库
• 采用Rust开发，整个系统的内存占用低

存储​

既然要把数据存储到磁盘，那就需要一个存储引擎。存储引擎的作用是把数据落盘，有组织有格式的存储在磁盘上。

自研一个存储引擎的工作量很大，而且目前开源有不少优秀的存储引擎，因此我们选用了开源的RocksDB作为存储引擎。

RocksDB是Facebook开源的一个Key-Value存储引擎，采用LSM Tree来组织文件，根据Key顺序存储在磁盘上，采用顺序写来替换随机写，极大的提升了写的性能。RocksDB对外提供的API只有简单的Get Put Delete Scan操作。

EasyCore存储的是图相关的结构化数据，RocksDB接收Key-Value数据，因此需要做一层编码转换Struct Data -> Key-Value。

基于Key有序的特性，我们使用以下原则来组织EasyCore的数据：

• 每个模型分配一个tid，模型的Schema以tid为Key进行存储，即tid -> Object Schema
• 实例tid_instanceId -> Instance

基于以上原则，也就是每类数据的Key都会包含一个命名空间的前缀，因此能快速查到模型下的实例。

Graph​

EasyCore是一个图数据库，需要具备图查询的能力，也就是能够根据一些点、一些边，查询出其所连接的点。

在EasyCore内部，实时维护了一个图结构，添加实例时，会往Graph中存储顶点，添加边时，会局部调整Graph的结构，确保顶点之间的关系是正确的。当需要查询某些边相关的点时，只需要在Graph应用一次Depth first search即可快速查询出结果。

Raft​

Raft 是一个强 Leader 的共识算法，只有 Leader 能处理客户端的请求，集群的数据（Log）的流向是从 Leader 流向 Follower。

基于Raft算法，将EasyCore的数据安全的复制到多个节点上，保证了EasyCore是分布式高可用。

Grpc​

EasyCore的协议层，采用Grpc协议。这一层，提供了图操作的相关API。

...未完待续

1.0 vs 2.0

• 大大简化了消息定义方式，减少 50%左右的重复消息定义
• 以领域模型对象为核心定义 model, 并附带校验规则，上层接口消费
• 消息内置于 request 和 response 内部，不需要显式声明 message, 定义更自然
• 将原先分散于各个组件的接口定义统一到契约中心

定义规范的目的​

• 标准化消息结构定义
• 标准化接口定义
• 增加消息约束校验能力
• 支撑 API 全面测试
• 支撑 RPC 框架功能强化

接口间用结构化的消息来进行远程调用。

目录结构​

contract-center
├── CONTRIBUTING.md
├── README.md
├── easyops
│   ├── api     # api 接口契约
│   │   ├── README.md
│   │   └── cd  # 持续交付产品 cd
│   │       ├── package # 包模型
│   │       │   ├── batch_update_package_permission.yaml
│   │       │   ├── create.yaml
│   │       │   ├── delete.yaml
│   │       │   ├── get_package_detail.yaml
│   │       │   ├── get_package_list.yaml
│   │       │   ├── get_package_permission.yaml
│   │       │   ├── get_package_user_variable.yaml
│   │       │   ├── init_package_permission.yaml
│   │       │   ├── search.yaml
│   │       │   ├── update.yaml
│   │       │   ├── update_package_permission.yaml
│   │       │   └── upsert_package_user_variables.yaml
│   │       └── version # 版本模型
│   │           ├── create_version_with_sign.yaml
│   │           ├── delete_version.yaml
│   │           ├── get_version_detail.yaml
│   │           ├── get_version_list.yaml
│   │           ├── get_version_permission.yaml
│   │           ├── update.yaml
│   │           ├── update_version_env_type.yaml
│   │           └── update_version_permission.yaml
│   ├── brick  # 构件契约
│   │   ├── README.md
│   │   ├── cd
│   │   └── common
│   │       ├── creator.yaml
│   │       ├── deleter.yaml
│   │       ├── editor.yaml
│   │       ├── explorer.yaml
│   │       ├── selector.yaml
│   │       └── viewer.yaml
│   ├── model  # 模型定义
│   │   ├── cd # 持续交付 cd 产品
│   │   │   ├── instance.yaml
│   │   │   ├── package.yaml
│   │   │   ├── package_ext.yaml
│   │   │   ├── version.yaml
│   │   │   └── white_permission_user.yaml
│   │   └── common
│   └── type  # 类型定义
│       ├── datetime.yaml
│       ├── email.yaml
│       ├── env_type.yaml
│       ├── file_path.yaml
│       ├── guid.yaml
│       ├── ip.yaml
│       ├── page.yaml
│       ├── page_size.yaml
│       ├── password.yaml
│       ├── user_name.yaml
│       ├── version.yaml
│       └── white_permisson_type.yaml
└── schema  # json-schema, 对 brick, interface, model, type 的定义进行约束
    ├── brick.json
    ├── interface.json
    ├── model.json
    └── type.json

模型定义​

模型是将我们产品中核心对象抽象出来，按核心对象进行定义，可以基本按数据库的设计，也可以有一些扩展模型。 一个示例定义(model/cd/package.yaml)如下：

_version_: 2.0 # 框架协议版本
_kind_: model # 契约类型为 model
name: Package # 契约名称
description: 包模型 # 模型简要描述
fields: # 模型字段定义
  - name: packageId # 字体名称
    type: guid # 字段定义
    description: 包 ID # 字段描述
  - name: name
    type: string
    description: 包名称
    validate: # 字段校验规则
      gte: 1
      lte: 45
  - name: type
    type: env_type
    description: 版本类型 1 开发, 3 测试, 7 预发布, 15 生产
  - name: cId
    type: int
    description: 包分类
  - name: source
    type: string
    description: 包文件源
  - name: repoId
    type: string
    description: repoId
  - name: repoPath
    type: string
    description: repoPath
  - name: memo
    type: string
    description: 备注说明
    validate:
      gte: 1
  - name: creator
    type: user_name
    description: 创建者
  - name: org
    type: int
    description: org
  - name: category
    type: string
    description: 包分类标签
  - name: icon
    type: string
    description: 包图标
  - name: style
    type: string
    description: 包图标样式(颜色)
  - name: ctime
    type: datetime
    description: ctime
  - name: mtime
    type: datetime
    description: mtime
  - name: authUsers
    type: user_name
    description: authUsers
  - name: installPath
    type: file_path
    description: 安装路径
  - name: platform
    type: string
    description: 平台

模型定义约束

模型文件命名规范​

命名规则

• 小写字母、下划线
• 模型的定义上线后，只能修改字段的描述，如果有字段类型的调整或者添加字段(不允许删除字段)，需要增加新模型文件，如 package_2.yaml

示例: model/cd/package.yaml

name - 消息名称​

命名规则

• 大写驼峰 name: Package

description - 消息描述​

示例: description: 包模型

imports - 引用的模型​

模型定义可以引用其它模型的定义，需要显式 import 到文件， 路径使用 / 分隔 示例：model/package_ext.yaml, 引用同级下的 Version 模型字段

_version_: 2.0
_kind_: model
name: PackageExt
description: 包模型

import:
  - easyops/model/cd/version

fields:
  - name: lastVersionInfo
    type: object
    fields:
      - ref: Version.ctime
      - ref: Version.name
      - ref: Version.versionId
    description: 最新版本信息
  - name: instanceCount
    type: int
    description: 包实例数量

fields - 字段定义​

• name：字段名 命名规范：小写驼峰 原因是 Go 和 JavaScript 的命名风格都是驼峰为主流。见 MixedCaps

• type：字段类型， 有三种来源, 基本内置类型、自定义类型、自定义模型

  • a. 目前内置支持的字段类型

• b. 在 easyops/type 下自定义的变量

  _version_: 2.0
  _kind_: type
  
  name: email
  type: string
  description: 电子邮箱地址
  validate:
    pattern: "^([A-Za-z0-9_\-\.\u4e00-\u9fa5])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,8})$/"
  

• c. 新的组合类型，object

  _version_: 2.0
  _kind_: model
  name: PackageExt
  description: 包模型
  fields:
    - name: lastVersionInfo
      type: object
      fields:
        - ref: Version.ctime
        - ref: Version.name
        - ref: Version.versionId
      description: 最新版本信息
    - name: instanceCount
      type: int
      description: 包实例数量
  

• ref 只能引用 model 中已经定义的类型 如果引用 model 中的所有字段， 可以是 Package.*

• enum 枚举，只作为字段的约束手段，不再是独立类型。 特别注意，自定义类型的时候，至少要有 enum 或者 validate 一种约束。

  - name: platform
    type: string
    enum: ["linux", "windows", "others"]
    description: 平台
  

• validate - 框架当前支持的校验方法

• 自定义 type

  _version_: 2.0
  _kind_: type
  name: white_permission_type
  type: string
  enum: [deleteAuthorizers, readAuthorizers, updateAuthorizers]
  description: 白色单权限类型
  

接口定义​

一个示例接口定义(api/cd/create.yaml)如下：

_version_: 2.0
_kind_: "interface"
version: 1.0
name: "Create"
description: "创建包"
import:
  - easyops/model/cd/package
endpoint:
  method: "POST"
  uri: "/package"
request:
  type: object
  fields:
    - ref: Package.name
    - ref: Package.type
    - ref: Package.cId
    - ref: Package.memo
    - ref: Package.installPath
    - ref: Package.platform
    - ref: Package.source
    - ref: Package.category
    - ref: Package.icon
    - ref: Package.style
  required:
    - Package.name
    - Package.type
    - Package.cId
    - Package.memo
    - Package.installPath
    - Package.platform
response:
  type: Package
  required:
    - Package.packageId
    - Package.name
    - Package.type
    - Package.cId
    - Package.memo
    - Package.installPath
    - Package.platform
    - Package.source
    - Package.category
    - Package.icon
    - Package.style

接口的定义约束

name - 接口名​

接口名命名规则

• 大写字母开头驼峰命名
• CRUD 对应的命名

接口文件名规范​

将 4.1 介绍的接口名转成小写下划线.yaml ， 如 list_process_log.yaml

version: 接口版本​

description: 接口描述​

endpoint: HTTP 资源​

request - HTTP 请求定义​

request 为空，则为 ~​

type​

type 代表请求消息的类型， 可以是 model 中的定义的具体类型 ，可以是自定义的 object 类型

• a. 当请求等于 model 中定义的所有字段，type 的类型为 model 中定义的具体类型 （大部分情况下都是 object） 示例:

  request:
    type: Package
    fields:
      - ref: Package.name
      - ref: Package.type
      - ref: Package.cId
      - ref: Package.memo
      - ref: Package.installPath
      - ref: Package.platform
      - ref: Package.source
      - ref: Package.category
      - ref: Package.icon
      - ref: Package.style
    required:
      - Package.name
      - Package.type
      - Package.cId
      - Package.memo
      - Package.installPath
      - Package.platform
  

• b. 当返回的所有字段不是在同一个 model 中定义的，请求的 type 类型为 object 自定义类型

  request:
    type: object
    fields:
      - ref: Package.packageId
      - name: permissionType
        type: white_permission_type
        description: 包权限类型
    required:
      - Package.packageId
  

fields​

当 type 类型为 object 时，需要自定义 fields 字段，定义请求的所有字段，这里的字段类型可以是自定义类型， 也可以引用模型中已定义的字段

当类型为 object 时，定义的详情参见 model 中的 object 定义. 示例如下:

request:
  type: object
  fields:
    - ref: Package.packageId # 引用 Package 模型的 packageId 字段
    - name: permissionType # 自定义字段
      type: white_permission_type
      description: 包权限类型
  required:
    - Package.packageId

response - HTTP 返回定义​

• 字段同 request 定义
• 框架或 sdk 会默认在 response 的 object 外封装一层

{ "code": 0, "error": "", "message": "", "data": response }

• 如果想自定义整个 response_message， 可以在 response 里面加上wrapper: false参数， wrapper 默认为 true。 eaml 版本 2.1 带有这个特性。

custom_controller​

这种一般都是接收了框架不支持的参数， 比如直接 post 一个数组过来，这时候需要配置这个设置

_version_: 2.0
_kind_: "interface"
version: 1.0
name: "GetPackageList"
description: "批量获取包信息"
import:
  - easyops/model/artifact/package
  - easyops/model/artifact/package_ext
endpoint:
  method: "POST"
  uri: "/package/list"
request:
  type: string[]
response:
  type: object
  fields:
    - ref: Package.* # reference package model
    - ref: PackageExt.*
  required:
    - Package.*
    - PackageExt
    - PackageExt.*

custom_controller: true

private​

接口是否私有，默认为 false. 如果是私有，不会向外部生成 api 文档

deprecated​

接口是否被废弃，默认为 false

接口定义与 HTTP REST 的转换​

新的后台框架采用消息契约编程模式，所以 HTTP REST API 的一些字段（body, uri 带的资源参数, query_parameter) 都要在通讯的消息定义中能找得到，以下是转换规则

POST​

不支持 http 的 query parameter(查询参数）

PUT​

同 5.1，注意，PUT 方法只支持对象全量更新操作，不要提供只更新部分属性的功能，否则会有坑。

实在要提供只更新部分属性的功能， 参考 google 的 fieldmask 设计。

DELETE​

uri 中的参数名称必须在消息中定义 http 的 query parameter(查询参数）名称必须在接口中定义 返回时消息为 null

GET 列表​

http 的 query parameter(查询参数）名称必须在消息中定义 返回时建议的消息结构为

GET 详情​

uri 中的参数名称必须在消息中定义 http 的 query parameter(查询参数）名称必须在消息中定义

API 版本号​

API 版本号要在 uri 里面体现出来， 如 /v1/xxx /v2/xxx

EasyOps 名字服务（以下简称 ens）扮演了 EasyOps 平台中这个指挥的角色。本文会从系统架构、用户使用的角度介绍 EasyOps 的名字服务。

功能​

ens 实现了以下功能：

• 服务注册

服务提供方需要向外提供服务的时候，会对外宣称自己提供的服务名和端口有哪些，启动的时候会自动把这个信息注册到名字服务里面，便于调用方能够发现这个服务。

在 EasyOps 平台里面，每个程序包里面的 package.conf.yaml 的描述文件里面会记录了这个程序包提供的服务

# 名字服务列表
service_list:
  - name: logic.dc_console
    port: 8087

• 服务路由

调用方需要知道被调方的地址时，通过 ens 提供的不同语言 sdk(c++, go, rust, py, java 等)获取被调服务的地址（ip+端口)。

• 负载均衡

当有多台主机提供相同的服务时，ens 会通过每台机器设置的权重来随机分配一个地址给到调用方。

• 自动容灾

当服务或者主机发生故障时，ens 会自动踢掉有问题主机提供的服务，实现自动容灾的功能。

系统架构​

总体架构​

总体的系统架构图如下：

• mongodb

mongodb 集群作为名字服务的中心存储，用于记录服务名与主机地址的对应关系。

• ens_root

缓存名字信息，分担 mongodb 压力。

• ens_client

在每台 EasyOps 服务端的主机都会装上 ens_client。

ens_client 会定时从 ens_root 同步名字信息下来。ens_client 提供缓存名字信息、服务节点发现功能。

此外， ens_client 还会定时上报主机心跳信息， 当心跳过期时，心跳过期的主机会被自动剔除。

• ens_sdk

缓存名字信息，提供不同语言的 sdk 给服务调用方使用。

高可用​

ens_root, ens_client, ens_sdk 都会有自己的缓存。任何一点故障，不会影响服务的正常调用。

ens 管理​

日常维护 EasyOps 平台时，我们经常需要管理名字服务。ens 提供了两个方法来对名字服务做读写管理。

控制台查看服务​

访问页面 http://\${EasyOps 平台 IP}/admin/ens 我们会看到所有的服务所在的地址

命令行工具查看、新增、删除服务​

• 查询名字下的 IP 端口 /usr/local/easyops/ens_client/tools/get_all_service.py 要查的名字

• 往名字里面注册 IP 端口 /usr/local/easyops/ens_client/tools/register_service.py 要注册的名字 要注册的端口 要注册的 IP（可选，默认本机 IP）

• 从名字里面删除 IP 端口 /usr/local/easyops/ens_client/tools/unregister_service.py 要注销的名字 要注销的端口 要注销的 IP（可选，默认本机 IP）

未来展望​

名字服务过去在 EasyOps 平台中扮演了核心的角色，未来 ens2.0 将会在多方面做优化。

• 结合契约中心做更多优化，比如支持按契约名及契约版本路由，支持路由的优先级。

• 除了 ip, port 以外，支持记录服务/契约相关的更多字段，如 host，契约版本号等。

• 更灵敏的自动容灾。

• 结合 CMDB 做功能更强大的控制台管理功能。

• -A、-B、-NA、-NB、-NT 是前台的 js 插件，本质是一个 js 文件。优维前端框架是基于插件式的开发，每一个页面都是由各个插件拼装而成，这样提供了非常灵活的定制化能力。详见 Brick Next
• _db 组件是各个组件的数据组件，提供了数据初始化和数据割接的能力，本身不会启动常驻进程

组件列表​

如下组件列表是build007 版本

EasyOps （console 3.16.0 +）支持接入客户已有 SSO 系统。配置如下： console.ini

事实上，每个客户的 SSO 的实现方式都有所差异，需要做一定的适配，更多接入示例参考可询问优维对接同学

“万物之始，大道至简”

本文尝试从简单的单元测试思想着手，探讨如何编写良好的单元测试。以下将主要基于 TypeScript, Jest, React, Enzyme 给出示例。关于单元测试的基本概念和重要性不在本文讨论范围。

基本方法​

编写单元测试的基本方法其实很简单：

1. 给定输入
2. 运行
3. 断言输出

而一个好的单元测试的要求也很简单：

• 覆盖足够的输入场景
• 进行充分的输出断言

一个最简单的例子：

// `add.ts`
function add(a: number, b: number): number {
  return a + b;
}

// `add.spec.ts`
test("add(1, 2) should return 3", () => {
  expect(add(1, 2)).toBe(3);
});

我们编写单元测试的步骤如下：

1. 给定输入：1, 2
2. 运行： add(...)
3. 断言输出：expect(...).toBe(3)

是不是很简单？当然，真实业务场景下我们要测试的单元远比上述例子复杂得多。

• 输入更加复杂，除了普通的函数输入参数，还可能有外部的事件，因此难以覆盖所有场景
• 输出更加复杂，除了普通的函数输出结果，还可能有对外部的副作用，因此难以断言运行结果

这里提到的输入、输出不再是狭义上的函数输入、输出。我们将所有可能影响测试对象行为的外部因素都称之为输入，将所有测试对象运行后对外部造成的影响都称之为输出。这样理解之后，我们就可以化繁为简，将测试过程回归到前面提到的最基本的方法上。

所以编写良好的单元测试首先要做的就是厘清测试对象的输入、输出，掌握覆盖不同形式的输入、断言不同形式的输出的方法。我们将分开讨论它们。

输入​

足够简单的输入让我们可以花更少的时间、覆盖更多的场景。输入的来源大致有以下几种：

• 普通变量参数
• 外部依赖发送的事件
• GUI 操作事件

编写测试覆盖它们的复杂度依次增大。除了第一个，其它都可以看作外部事件，也可以理解为来自外界的副作用。对于普通变量参数，我们只需构造这些参数即可完成给定输入的任务。而对于外部事件，我们要做的就是想办法触发这些事件。

我们依然看一个简单的例子：

// `MyComponent.ts`
window.addEventListener("resize", () => { ... });

如何覆盖？主动发送这个事件：

// `MyComponent.spec.ts`
test("MyComponent", () => {
  window.dispatchEvent(new Event("resize"));
  // ...
});

再看一个例子：

// `MyComponent.tsx`
const handleChange = (value: string): void => { ... };
return <Editor onChange={handleChange} />

如何覆盖依赖组件的特定事件？主动触发依赖组件的事件：

// `MyComponent.spec.tsx`
test("MyComponent", () => {
  const wrapper = shallow(<MyComponent />);
  wrapper.find(Editor).invoke("onChange")("faked value");
  // ...
});

输出​

足够简单的输出让我们可以更容易地断言运行结果。输出的形态大致有以下几种：

• 普通变量输出
• GUI 的变化
• 外部依赖的调用

在测试中对它们进行断言的复杂度依次增大。除了第一个，其它都可以看作对外界的副作用。对于普通变量输出，我们只需简单地断言它的值即可。而对于对外界的副作用，我们要做的就是想办法断言这些副作用的影响。

我们继续看一个简单的例子：

// `handleClick.ts`
function handleClick(): void {
  history.push("/next/url");
}

如何断言？我们可以断言副作用的影响结果：

// `handleClick.spec.ts`
test("handleClick", () => {
  handleClick();
  expect(history.location.pathname).toBe("/next/url");
});

有时副作用所影响的结果难以断言，或者该依赖被 Mocked，那么我们可以监视该副作用的触发点是否被正确调用了：

// `handleClick.spec.ts`
test("handleClick", () => {
  const spyOnHistoryPush = jest.spyOn(history, "push");
  expect(spyOnHistoryPush).toBeCalledWith("/next/url");
});

再看一个 React 组件的例子：

// `MyComponent.tsx`
const handleValidation = (valid: boolean): void => {
  this.setState({ valid });
};
return (
  <Form.Item className={this.state.valid ? "valid" : "invalid"}>
    <Input />
  </Form.Item>
);

如何断言？判断依赖组件的变化：

// `MyComponent.spec.tsx`
test("MyComponent", () => {
  const wrapper = shallow(<MyComponent />);
  // ... after something trigger `handleValidation()`
  expect(wrapper.find(Form.Item).prop("className")).toBe("invalid");
});

始终记得要断言测试对象运行后对外界的副作用影响。

另外断言的目标应该是对外的影响，而不是内部状态，因为内部状态并不是测试对象的输出。一个错误的例子：

// `MyComponent.bad.spec.tsx`
expect(wrapper.instance().state.valid).toBe("invalid");

重构与拆分​

更简单的输入、输出让我们可以更容易地编写好的单元测试，但往往实际情况是业务需求不断增长，组件内部逻辑不断复杂化，输入输出的形式形态更加多样化，为组件编写单元测试的难度也随之陡增。

适时地重构与拆分是解决这个问题的关键。在如今的前端组件化的模式下尤为重要，合理拆分后的组件可以让每个测试单元的输入输出都变得更少、更聚焦。诸如 React, Redux 等主流框架和工具推崇的单向数据流盛行的其中一个原因就是它们巧妙地让各个单元的输入来源、输出影响单一化，从而降低编写单元测试的难度，同时提升组件集成时的信心。

总结​

编写良好的单元测试总结下来就是三条：

• 识别测试对象的输入、输出
• 掌握不同形态下的输入覆盖、输出断言的方法
• 适时地重构与拆分

希望以上内容对大家有所帮助。