组件完整交付流程的思考

基于 Stencil 构建 Web Components 组件库专栏目录总览

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

前面所有的章节,都是为组件库的「起航」做准备。那么在我们迭代组件库或者开发新组件的时候,也会遇到研发交付流程问题,那么我们该如何组织一个组件库的研发交付流程呢?接下来我们从几方面从头到尾来仔细的研讨下。

PS:我们这次以一个公司的组件库研发为背景来探讨。

提案

提案是一个组件库增加新的组件或者扩展组件功能的最初起点,在提案阶段,我们应该充分考虑一个组件的合理性、必要性、及初始功能。

一般提案是由具体业务发起,在业务中发现组件库所欠缺的组件,由此为开始,经过调研其他组件库的功能点和业务需求,发起提案。比如需求案例如下。

根据需求文档,我们需要一个 message 组件,用于给用户提示操作反馈和一些信息。此时我们先收集需求文档中需要的功能点:

  1. 需要有一个倒计时关闭功能;
  2. 需要有一个按钮用于提供给用户反馈;
  3. 需要有手动关闭按钮。

收集到需求里面的功能点,这时整体功能还不是特别完整,我们需要去调研一些成熟的组件库,来补充完善一些功能,调研结果如下:

Semi

组件完整交付流程的思考

AntDesign

组件完整交付流程的思考

ElementUI

组件完整交付流程的思考

经过调研和总结,我们补充需要以下功能点:

  1. 倒计时关闭功能;
  2. 回调按钮提供给用户反馈操作;
  3. 手动关闭按钮配置;
  4. 弹出位置:顶部、底部;
  5. Icon 自定义功能;
  6. 距离顶部位置。

经过一轮完善和调研后,我们就可以发起提案了,提案包括以下内容:

  • 需求功能点;
  • 调研结果;
  • 开发估时;
  • 其他补充内容。

提案阶段主要是为了对将要开发的组件做一个深层次的了解和调研,可以让我们对此组件对于业务的需求更加有把控,这也是打好组件开发根基的重要一环。

UI设计&评审

这个阶段主要工作量是UI和产品经理来控制,通过提案的内容功能点,设计出相应功能点的 UI 图,这个过程中,设计师也需要去一些成熟的组件库汲取下经验,通过和提案发起者的反复沟通,给出当前组件各种功能点各种状态的设计图。

组件完整交付流程的思考

PS:这时候推荐一波 masterGo 蓝湖出品的一款非常好用的设计协作软件,可以同时连通设计师和研发工程师、产品经理,让你的效率成倍提升。

设计图完成后需要产品和研发同学进行评审,主要审查以一下设计状态是否完善、结构是否合理、资源是否完善。

UI 设计和评审阶段也是确定组件研发工作量的最后一环,在这个阶段我们应该重新审查下自己的工作量是否是合适。

研发任务分配

研发任务分配阶段主要产出两个产物:

  • 功能case脑图;
  • 具体实现技术方案。

测试case脑图是整个组件的开发脉络,一个组件逻辑是否完整、功能点是否覆盖完全都可以在这个脑图中所体验,这个脑图也是一个开发的大纲,我们单元测试和e2e测试都可以按照这个脑图进行,所以在这个阶段产出一个大纲脑图是非常有必要的。

技术方案是偏实现的一部分,内容包含了:组件该如何组织内部结构、具体实现方案细节、一些必要的技术设计和实现。这些部分主要是让其他共同开发的同学预先了解下你的开发思路,如果有一些不合理的地方,可以及时修正,避免额外的工作量。

组件技术方案评审

这个阶段就是对上面的脑图和技术方案进行评审,这个阶段可以邀请更多的同学进行参加,俗话说,众人拾柴火焰高。有些潜在的问题和没有考虑到的功能点逻辑,都有可能在这个环节发现暴露。所以,技术方案评审的环节还是很重要。

同时,一场技术评审会,也可以让大家有一定的空间进行交流、发散自己的思维,就像一场技术分享会一样,给大家带来的收益是比较大的。所以,如果条件允许,不管是组件方案评审还是其他的技术方案评审,我们都应该尽可能地参加,提升自己的技术视野。给自己带来成长。

组件研发

此阶段涉及到了我们的 workflow 该如何制定,其中比较重要的一点就是 git flow 的制定,我们应该如何去设计我们的开发 git流程。

组件完整交付流程的思考

如上图,我们应该设定一个清晰直接的 Gitflow 流程来规范我们的开发行为。

研发自测

自测也是一个研发人员最基本的素养,我们应该对自己开发的组件或者功能负责,在开发完成后,我们应该按照我们上面测试 case 脑图进行逐个 check 的操作,这个步骤是必不可少的,也是我们开发代码自我检查的最后一道关卡,如果我们上面脑图case足够完善的话,这一步也是很容易完成。

除了按照case自测,我们也应该应该从一个使用者的角度,对组件进行审视和试用,尽可能的覆盖各种复杂的使用场景和极端case。尽可能的早暴露一些潜在的问题。

研发交叉测试

这个阶段主要是为了做一个黑盒测试,因为组件的直接使用者就是前端的同事,所以组织同事对你开发的代码进行一轮交叉测试还是很有必要的,在你自测没有发现的问题,这一环节也就很有可能暴露出来。

UI 走查

这一环节是需要 UI 同学参与进来对 UI 样式进行一层把控,对于一些 UI 上的问题进行验证和修复,也是对于 UI 的最后一层验收环节。

代码Review

这个阶段也有一定的原则:

需要大于等于2人进行确认后才可以合入release分支。单元测试覆盖率必须覆盖所有的脑图case。文档说明必须完善。

这三个点都比较重要:

  1. 需要大于或等于2人的确认代码才可以合入是为了保证代码的合理性,因为每个人看待代码的角度都不一样,而且由于每个人的一些不确定性,很容易将问题忽略掉,而我们需要大于等于2人来检查代码就是为了把这些风险降到最低,在合并代码之前解决的问题不算问题,等合并上线后的问题就是bug,所以做这一步也是非常有必要性的。
  2. 单测和e2e测试,这两项一直是用来保证组件稳定性的法宝,当我们进行组件的扩展或者改动的同时,测试同学很难把所有的测试用例都覆盖完全,因为这个工作量是相当的庞大,所以单测和e2e测试的覆盖率就是为了自动化的脚本可以保证代码质量和组件的稳定性。
  3. 文档是一个组件的使用说明书,也是使用者最需要的内容,所以你的组件文档是否完善也是很重要,也必须进行一层check,查漏补缺。

而代码 CR 也是一个非常重要的环节,并不只是高等级的程序员才可以进行cr,我们平常同事之间也可以进行一些 cr 的工作,在 cr 过程中我们可以相互学习一些编程的思想和技巧,这对自己也是一个很大的提升。

交付发版

以上所有步骤都走完以后,你的新组件就可以合并到 master 分支进行自动化发版了。也是最后交付的环节。

所以总结起来,所有的流程如下:

组件完整交付流程的思考

写在最后:

本文旨在引导大家对 Stencil 以及 Web Components 做一个简单的了解,对于一个组件库的构建流程和设计架构做一层简单的学习,但是在这个过程中,涉及到的知识点比较多,我只能挑拣一些重要的进行说明,可能造成整体脉络不太连贯,或者忽略了一些知识点。给大家带来了困扰,在此深表抱歉,如果大家有问题,可以添加进小册的群进行探讨。

最后希望大家在前端的道路上走出自己的特色,把我们中国前端的影响力在世界范围提升上去,实现自己的价值。

示例代码:https://github.com/fanshyiis/sten-components-demo

 

免责声明:
1.本站所有内容由本站原创、网络转载、消息撰写、网友投稿等几部分组成。
2.本站原创文字内容若未经特别声明,则遵循协议CC3.0共享协议,转载请务必注明原文链接。
3.本站部分来源于网络转载的文章信息是出于传递更多信息之目的,不意味着赞同其观点。
4.本站所有源码与软件均为原作者提供,仅供学习和研究使用。
5.如您对本网站的相关版权有任何异议,或者认为侵犯了您的合法权益,请及时通知我们处理。
火焰兔 » 组件完整交付流程的思考