作者：刘恒兵
为什么要做组件平台
为什么要组件，这个问题在很多场合都被人提起，这里不做过多赘述，其解决的本质问题：
- 复用：减少产品、设计(UI)、开发、测试、部署(大型应用)的重复工作量，提升开发效率
- 统一：同一个平台统一产品特性保持高度统一和一致，能做到同步修改。
然后，在任何产品的上线过程中，谁都不愿意重复早轮子，都希望能通过一些规范和标准统一起来，后续就完全按照这个标准执行，并能否把历史上实现过的沉淀出来的直接使用，不需要重复劳动。
这里就提到的重要的点：1、沉淀；2、标准。如何沉淀？沉淀的标准是？在哪里沉淀？该不该使用？如何使用？新加入的小伙伴如何知道？
同时，我们还需要解决每个组件之间的依赖（即模块依赖），就需要一个平台来帮我们做这样的事情，维护组件，而且能做到工具化，和构建体系打通，使用者能快速方便地相信和使用组件。这里就提到一个重要的问题：工具、维护
从组件的维护发展历史来看有以下一些方式：
- svn：把一些组件抽离出来，放到代码管理系统，使用者通过既定的发现路径，招到组件，下载使用。这种方式效率相对比较低，团队内部都不一定能知道对方有什么组件，外部更不用说了。
- github：相对于svn来讲，除了代码托管之外，比较优势的地方是开源化，可以在这个平台找到很多有类似功能的组件。同时，还可以参与贡献和反馈，提升组件。然后，对于使用者来讲，首先要找到自己想要的组件相对麻烦；同时，和自己的构建体系结合，依赖维护等都是比较明显的问题。
- Npm、Bower，Browserify，Component、Duo、Jamjs等。他们都能解决组件依赖，同时也能和构建体系打通，有很多关于他们对比的文章，这里不做更多描述。他们在很大程度上解决了我们工作中遇到的问题。但随着组件的增多，我们逐渐发现，找一个组件（且是自己信任和想要的组件）比较难，只能根据知名度、关注度以及文档来初步判定，而且没办法反哺组件，进一步提升组件
- Spm：这里之所以单独列出来，一度我们觉得这个是离我们目标最近的组件管理平台，他包括了组件初始化、编码、本地化调试、文档生成、发布、依赖管理、单元测试、构建、源服务等功能。
而我们理想需要的一个组件管理平台应该要满足以下条件：
更新维护文档调试依赖管理构建体系单元测试快速发现质量认证使用反馈
那么，现有的哪个平台离我们最近呢？之前的分析可以看到，离我们最近的是spm，基于spm我们可以打造出我们理想目标的组件管理平台。
如何着手做呢
开始之前我们得明确自己的目标，有了目标之后我们得确定规范，然后才能开始行动。
规范
每一个组件平台应当有自己的规范，至少应该包含以下规范：
当然这里的运营规范是后面补充的，早期我们确定了代码采用commonjs规范，后期我们打通了基于fis3的构建体系fis3-hook-lego。其他构建体系下的插件也会逐渐放出来。
全景图
规范确定之后，应当有一个整个平台全景图的规划，应该罗列需要包含的功能。
认证流程
其中我们想要的认证体系如下：
平台开发
组件使用
这里有详细的组件使用文档
大致罗列了一下，Lego的产生的背景、规范、使用的指引，后续章节再逐渐解析Lego体系下各个模块运作机制和Lego的理念
