这个东西是开发者开发项目时对于各类配置的最终解决方案。将所有配置纳入统一管理，以一种统一的方式。
目的是解决各种配置的让开发者陷入无尽疯狂的问题。
具体特性有：
- 自动识别项目类型标签(如：
npm``unity)，并直接按照项目类型给予配置支持。 - 对所有配置给予可视化支持，且援引相关的资料和帮助
- 可以依据社区实践，帮助开发者筛选推荐的配置/不可行的配置，并将自己的配置进行分享
具体特点有：
- 通用，为的就是希望在现实世界中没有配置的壁垒，无论做什么类型的项目，都能给你最大程度的配置帮助
- 通用，无论你的配置文件是json还是xml还是yaml。
- 全局，无论你是配置环境还是配置测试还是配置插件还是配置编辑器还是配置ide
- 智能，推理的方式可以很大幅度解决整合的问题
- 可靠，这个东西是给人用也是给机器用的
原理
概念
项目类别树
具体而言，某些项目类别可能是另一些项目类别的子类。
比如，一个react项目一般情况下是npm项目。
对于这类情况，需要按照项目类别属性，一层层的设置各类别专门需要的配置信息，并一层层合并(如：react项目只需要配置react的部分，当然也会满足并嵌入到npm的配置中)
规范
所有使用工具的配置项(无论是工具的声明使用，还是工具内部配置项)，都必须在指定这个配置的地方紧跟着指出该配置项的文档链接
必须有一个提前的声明，指定实现哪一个功能特征是让哪一个流程/工具去做的。尤其是很多工具一块用但是也“提供了可能的特征解决方案，但是不绝对可靠”的情况
具体实现的状态空间可能性必须减小到和你的需求同级
不但关注各配置项的存在性，还要去关注其关系和联系。比如，各配置项的顺序非常重要。
绝对不要让用户去关心配置的底层细节问题。这是个无底洞
解决方案：
- 除非让这些配置涉及到的底层的东西非常非常少。但实际上基本不可能。但是如果做到了收益会极高
- 开发者把底层实现做的非常好。或者如果出现问题，也可以让用户不关心底层情况的前提下找到答案
配置设计
你如果要做一个可以让别人使用的需要配置的功能单元，你的配置需要满足这些条件：
- 必须给出配置的模式和校验规则。
- 配置中任意单元项都必须提供相应说明，包括但不限于：
- 这个配置联系到了功能单元的哪一部分
- 该配置项各种可能取值对应的运行效果
- 配置决定运行过程，还是可以观测到该配置如何起作用
- 如果配置直接决定了运行结果的一部分，给出通过运行结果的情况推断出配置情况的简单方法
- 如果配置项是与另一个功能单元的配置项相对应（作为接口），指出这种对应关系，并在使用这种对应关系时，向用户告知双方的对应配置是否对应的上
若有收获，就点个赞吧
0 人点赞
