转载

Lego组件平台开发（一）

@(lego平台)

为什么要组件，这个问题在很多场合都被人提起，这里不做过多赘述，其解决的本质问题：

然后，在任何产品的上线过程中，谁都不愿意重复早轮子，都希望能通过一些规范和标准统一起来，后续就完全按照这个标准执行，并能否把历史上实现过的沉淀出来的直接使用，不需要重复劳动。

这里就提到的重要的点：1、沉淀；2、标准。如何沉淀？沉淀的标准是？在哪里沉淀？该不该使用？如何使用？新加入的小伙伴如何知道？

同时，我们还需要解决每个组件之间的依赖（即模块依赖），就需要一个平台来帮我们做这样的事情，维护组件，而且能做到工具化，和构建体系打通，使用者能快速方便地相信和使用组件。这里就提到一个重要的问题：工具、维护

从组件的维护发展历史来看有以下一些方式：

svn：把一些组件抽离出来，放到代码管理系统，使用者通过既定的发现路径，招到组件，下载使用。这种方式效率相对比较低，团队内部都不一定能知道对方有什么组件，外部更不用说了。
github：相对于svn来讲，除了代码托管之外，比较优势的地方是开源化，可以在这个平台找到很多有类似功能的组件。同时，还可以参与贡献和反馈，提升组件。然后，对于使用者来讲，首先要找到自己想要的组件相对麻烦；同时，和自己的构建体系结合，依赖维护等都是比较明显的问题。
Npm、Bower，Browserify，Component、Duo、Jamjs等。他们都能解决组件依赖，同时也能和构建体系打通，有很多关于他们对比的文章，这里不做更多描述。他们在很大程度上解决了我们工作中遇到的问题。但随着组件的增多，我们逐渐发现，找一个组件（且是自己信任和想要的组件）比较难，只能根据知名度、关注度以及文档来初步判定，而且没办法反哺组件，进一步提升组件
Spm：这里之所以单独列出来，一度我们觉得这个是离我们目标最近的组件管理平台，他包括了组件初始化、编码、本地化调试、文档生成、发布、依赖管理、单元测试、构建、源服务等功能。

而我们理想需要的一个组件管理平台应该要满足以下条件：