背景

本周有幸得到机会，参加了2021北京Qcon第一天下午半场《大前端工程化》的主题，简要对这部分内容做一些记录。

Qcon -《大前端工程化》

本次《大前端工程化》一共有四个嘉宾负责发言，其主题分别为：

美团移动端持续交付实践 – 邓常强

Coding is Easy and Fun：字节跳动本地研发生态链 MBox – 詹迟晶

P2C – 淘系频道业务需求结构化平台 – 郭启织

中小型团队的前端工程化实践 – 王泽

接下来分别对主题中主要的内容进行描述，大家理性看待，仅供参考

1.美团移动端持续交付实践

主要内容：

首先，传统的开发流程如下：

需求 -> 开发 -> 构建 -> 测试 -> 发布 -> 运维

持续交付的过程是开发流程的自动化/工程化的方法。虽然有嘉宾主题定语限制移动端，但是实际上分析过程中的持续交互逻辑，适用于其他场景。

主讲对于美团的移动端持续交付体系的3个阶段演变进行了简述：

阶段一：本阶段的目标主要集中在质量保障，因此通过Jenkins + GIt的方案，解决从开发，构建，发布流程的基本功能。除此以外本阶段前端工程已经开始从一个大项目，往模块化的方式进行转换，我们需要把项目拆分成模块进行开发，最后发版上线需要合并成统一的包，因此需要自动化的持续交付过程帮助完成代码的合并等操作

阶段二：本阶段的目标主要集中在协同，由于项目的逐渐模块化以后，多应用（美团APP，外卖APP，点评APP）之间的复用，逐步从模块化 -> 转换为组件化，动态化，在转换过程中，需要对现有的持续交付方案进行升级，一方面需要扩大质量保障过程中的检查范围，另一方面需要处理不同团队间协同所带来的问题（比如组件的版本，组件变更质量保障等）

阶段三：本阶段的目标主要集中在自主控制，前两个阶段中，整体的持续交付流程都是依赖已有的持续交付方案，但是已有的持续交付方案中，可能存在无法定制的程度，从组件化，动态化 -> 跨站，跨平台，容器化的变化的过程中，需要添加更多的内容来保障整个持续交付的智能和稳定，因此从这个时候开始着实自研的解决方案，并进行持续交付工具的平台化建设，且对于开发流程的关注阶段，也从最构建发布过程，持续扩展到了开发流程的全链路

个人观点：

持续交付在软件开发过程中的有着很重要的地步，其核心是确保功能是确保开发流程链路的快和准。

自己处于该体系下，主讲分享内容本身并没有太多能给自己冲击的地方，内容本身讲的大而全，对没有持续交付概念的工程师来说，应该很有收获；但对于已经熟知这个概念并已经使用过比较完备的持续交付方案的工程师来说，整个主题内容略微有点无聊（讲的有点太宽泛，不够具体）。

2. Coding is Easy and Fun：字节跳动本地研发生态链 MBox

主要内容：

Mobx（非React的Mbox，类似于VScode的IDE开发工具）的核心内容是为研发提供更好的体验。从研发过程中的四个环节：Enviroment, Workspace, WorkFlow, Tools进行了体验改善，

对图中的每个环节进行描述：

Enviroment：主要关注点在于研发环境的，一方面对于不同语言（Android，IOS，Ruby，Web）的研发人员，在研发过程中我们所需要的第一步就是开发环境的配置，但是传统的流程都是各自安装各种环境（例如，以web开发为例：Node，Git，VsCode等等），而各自安装的过程会导致更多的不统一（例如：Node版本不统一导致的自研组件报错等），因此Mbox利用沙箱的机制，把环境的这个过程直接解决掉了，研发前不再需要自行安装环境，只需要一键就可以完成相关语言开发环境的搭建，且保持了和其他研发人员开发环境的统一，同时，由于沙箱机制，很容易在不同的研发语言，研发环境中进行切换且互不影响

Workspace：主要关注点在于研发过程中的多仓库，仓库依赖，代码同步的问题。同样利用沙箱的机制，按照Feature对功能代码进行管理，此时，将以前的分支切换/并行开发过程，变成了多Feature并存的过程（和clone多次工程，不同工程使用不同分支一个效果，只是这一步更智能了），同时因为沙箱的机制，在新人跟进开发的时候，直接将当前的Feature分析给相关人员，相关人员就可以拿到完整的符合预期的代码并进行本地运行

Workflow：主要关注点在于研发工作流，讲的例子是一个Crash问题排查的场景，将Crash通过采集以后，可以直接在Mbox运行问题出现的场景，帮助更快的解决线上问题

Tools：涵盖基本的研发过程中所需使用的各种工具集合，例如：Optimize，Formatter等等

个人观点：

四个主题中，这个主题是让我觉得最有趣的主题，也是收获最多的主题，因为他的关注点在于研发人员。

Mbox本质还是一个IDE，因此在主讲者讲述过程中，我一直在思考，Mbox和VScode有撒区别？Mbox提供的功能，我们可以通过各种工具的整合实现，但是Mbox的核心关注点还是在研发过程的体验上，为我们工程师自己服务这件事，这是很cool的。我们创造的东西去尝试改变世界，但是逐渐我们习惯了繁琐，我们认为改变世界就应该承受这种繁琐，但是我们不应该也要改变这种繁琐而不是接受他么？

提问环节有人问了一个主讲者一个问题：

如果Mbox提供的流程不满足我们现在的研发流程方式，Mbox可以进行自定义调整么？

主讲人的回答很有意思，大概意思：

Mbox提供的是标准流程，按照这么做是业界标准，如果不按照这个标准，那么本身研发流程是否是有问题的？

也许听起来有些自大，但是我最关注的点还是做产品的时候不要被特殊场景所裹挟，而是要去制定标准，在完善的调研以后，告诉用户我这个比你现在的方式更适合你，我觉得是产品过程中很重要的点，发掘用户真正所需要的东西。

3. P2C – 淘系频道业务需求结构化平台

主要内容：

主题的核心观点是在于从D2C（Design to Code：设计图转换为代码）往P2C（PRD to Code：需求文档转换为代码）思路的转变，以及P2C核心实现机制。

首先为什么是P2C而不是D2C，由于Design标准化转换为Code，能解决的是图->代码的问题，但是实际上研发过程中，图和需求是相关的，因此，单纯从图->代码的过程只能解决第一步的问题，而研发中最主要的问题还是业务逻辑，这些通过图是没办法表现的，如果只停留在D2C，那么就是一个半成品，所以才考虑从D2C往P2C转换

P2C实现目前按照两种方向进行：人工标记和NLP解析

人工标记的方案是目前场景下更容易操作的方案，通过提供给产品经理相关的平台工具，其通过平台工具，利用现有物料组装页面（low code部分），然后人工标记的方法，补充完整且详细的交互逻辑（例如：按钮点击后弹窗，按钮点击后颜色变化，变成什么颜色，等等）

NLP解析，则通过输入的文本，利用语义解析的方案，自动完成交互逻辑的变化

个人观点：

认识的小伙伴中有做这方面研究的，所以提前对这个主题有一定的了解，P2C是一个很好的问题解决方向，让不会编写代码的人，可以通过标记+自然语言产出标准的产品；同时利用P2C的平台工具对产品发生变化时进行变更记录，比用现在的文档记录能更加直观的体现需求变动带来的视觉变化。未来方向肯定是很棒的，尤其在NLP领域突飞猛进的现在，以后也许真的不用关注业务代码的开发，研发可以更多关注创造