作者:刘恒兵

为什么要做组件平台

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

  • 复用:减少产品、设计(UI)、开发、测试、部署(大型应用)的重复工作量,提升开发效率
  • 统一:同一个平台统一产品特性保持高度统一和一致,能做到同步修改。

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

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

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

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

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

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

  • 更新维护
  • 文档调试
  • 依赖管理
  • 构建体系
  • 单元测试
  • 快速发现
  • 质量认证
  • 使用反馈

那么,现有的哪个平台离我们最近呢?之前的分析可以看到,离我们最近的是spm,基于spm我们可以打造出我们理想目标的组件管理平台。

如何着手做呢

开始之前我们得明确自己的目标,有了目标之后我们得确定规范,然后才能开始行动。

规范

每一个组件平台应当有自己的规范,至少应该包含以下规范:

当然这里的运营规范是后面补充的,早期我们确定了代码采用commonjs规范,后期我们打通了基于fis3的构建体系fis3-hook-lego。其他构建体系下的插件也会逐渐放出来。

全景图

规范确定之后,应当有一个整个平台全景图的规划,应该罗列需要包含的功能。

认证流程

其中我们想要的认证体系如下:

平台开发

开发之前,有做过一些深入的交流和讨论,基于客户端开源

组件使用

这里有详细的组件使用文档

大致罗列了一下,Lego的产生的背景、规范、使用的指引,后续章节再逐渐解析Lego体系下各个模块运作机制和Lego的理念

原文链接:http://ivweb.io/topic/561722725d6f37745e8f4979

文章来源于腾讯云开发者社区,点击查看原文