目标

分享配置化在定制化场景的应用
提供一套完备的定制化开发流程

背景

不同于 C 端产品 B 端产品是面向企业用户的产品，是用来解决企业具体需求的，为了应对更多的业务场景，能够较低成本的满足丰富多变的业务需求，B 端产品在设计时就需要考虑产品的灵活性，这也是 B 端产品设计中的重要原则。

然而在面对具体业务场景时，B 端产品经理容易按照已经明确的需求，做成固化的方案，从而导致最终开发同学的代码也是固化的，后面如果客户出现一些需要定制化的需求，就需要开发人员针对性的进行定制化开发。

定制化开发难点

相比于传统的标品化系统开发，定制化开发的特点明显，开发人员需要在定制化分支上对项目源码进行更改，最终交付这个定制化分支的代码，这种开发方式会存在下面几个问题：

开发成本高

目前定制化的需求都是交由 DRD 去完成，那 DRD 就需要了解整个项目的代码，学习项目的开发规范。
维护成本高

针对定制化需求，目前都是单开分支进行开发交付，分支一多后期的维护成本就变高，比如bug的修复等。
公司交付要求

按照公司的要求，对于私有化交付是禁止直接交付项目源码。

如何提升产品灵活性

预测需求

预测需求指的是在在思考一个需求方案时，需要同时预测未来业务中可能出现的多种场景，并提前做好普适方案，这种方式能在一定程度上提升产品的灵活性，但同时也有比较大的局限性：

需要深入了解业务场景，能够精准的预测未来可能出现的场景。
能够提前设想的场景是有限的，因此该方案使用的范围也是有限的，不能做到完全的灵活。

所以这条思路主要应用于需求场景较少且容易明确的功能。

可配置化

可配置化指的是将产品功能做成灵活可配置的，通过不同配置的组合来满足各种定制化场景的需求，这种方案灵活性更高。业界也有可以借鉴的例子，比如 jupyterlab。

? JupyterLab 是一个高度可扩展、功能丰富的笔记本创作应用程序和编辑环境，相较于Jupyter Notebook JupyterLab 提供了更先进、功能丰富、可定制的体验，目前 star 数已经 10k +，是一个非常优秀的可配置化项目。

可配置化能带来哪些收益？

在 xmind 定制化开发的场景中，通过可配置化能带来下面几个收益：

降低定制化开发成本

有了配置化之后，DRD 的关注点由原来的整个项目编程一个配置文档，DRD 只需要根据配置文档更改配置文件就能完成定制化功能开发。
降低维护成本

在可配置化的模式下，定制化开发不需要单独的分支进行维护，只需要维护一个配置文件。
避免交付源码的场景

需要怎么做？

总结项目高频的定制化场景
对定制化功能进行抽象，抽象成对应的配置项

比如下面这种场景，标红的是用户想删除的功能：

该场景下用户的需求主要是控制某些标品功能的展示，针对这种场景，配置项可以细粒度到具体的功能。

```tsx
{
    showCreateUserBtn: boolean; // 是否展示创建用户按钮
    showDeleteUserBtn: boolean; // 是否展示删除用户按钮
    userRowSelection: boolean; // 用户列表行是否可选择
    showUserName: boolean; // 用户列表是否展示用户名称
    showUserStatus: boolean; // 用户列表是否展示用户状态
    showUserRole: boolean; // 用户列表是否展示用户角色
    showUserUsefulLife: boolean; // 用户列表是否展示用户过期时间
    showUserDescription: boolean; // 用户列表是否展示用户描述
    showUserCreateTime: boolean; // 用户列表是否展示用户创建时间
}
```

配置文件如何在项目中使用可参考下面一篇文章 DI 在定制化场景的应用。

定制化开发流程

提供脚手架，搭建开发环境

客户的定制化需求除了对样式、标品功能的展示做定制化之外，还可能需要在标品的基础上额外增加新的功能，此时就需要给 DRD 提供一个完整的的开发环境，之后定制化功能可以在运行时作为子应用接入到标品应用。
提供微前端本地开发工具，在沙盒环境进行功能测试

定制化功能本地开发时需要对功能进行测试、联调，这里可以借鉴 single-spa 推荐的微前端本地开发模式。
部署交付

更详细的开发流程可作者参考这篇文章高效的微前端开发流程。