在我们划分了团队之后，发现还存在一个独立骑手的参与方，但这个角色看起来是多余的。

上线之后立马遇到了问题：

1. 门店有多个员工轮流值班，公用账号的问题。
2. 后续会通过小程序给门店付钱，要控制提现的权限。
3. 实际进行配送的可能不是一个骑手，而是多个人按照目的地来分配任务。
4. 骑手也存在与第 2 点相同的问题。

最开始设计的系统。没有考虑那么多，所以门店和骑手其实是作为系统的基础数来看待的，是系统的一部分。
然后给每个门店分配一个店长，给店长分配一个业务账号，给骑手自身分配一个业务账号。

一个 API 的设计迭代案例…

一个真实的反模式 API 设计案例…

用工具支持 monorepo 模式。

在做一般的应用产品开发时，通常会基于特定的平台（比如 Android、iOS）、框架（Vue、React）或者技术标准（Servlet）等等。
这些开发平台通常经过精心设计，给程序员提供一个受控环境和开发模板，程序员在这个特定的环境中按照开发平台的规范进行开发。

集错误之大成：前朝的剑斩本朝的官。

小程序App、Page 和 Component 是通过函数调用的方式来实现创建的，通过函数参数 option 来定义数据和行为，通过 Behavior 来实现复用。
但是在抽象组件的时候，会面临几个问题：

1. 小程序没有继承体系。
2. 部分 option 的属性无法通过 Behavior 来组合/混入。

由于小程序没有使用“组件类”的构造方式，无法使用继承，因此，小程序框架提供了“混入”（mixins）方式的复用机制，“混入”主要通过 Behavior 来实现。
根据官方的定义：

每个 behavior 可以包含一组属性、数据、生命周期函数和方法。组件引用它时，它的属性、数据和方法会被合并到组件中，生命周期函数也会在对应时机被调用。每个组件可以引用多个 behavior ，behavior 也可以引用其它 behavior 。