2020.3.28 前端早早聊第三期 主题「前端可视化搭建|智能搭建
活动开始前，我先抛出这样一些问题，带着问题去听：
- 为什么需要搭建
- 搭建前后对比效果
- 搭建过程中遇到哪些问题，如何解决
- 搭建项目产出后有什么感悟
- 搞搭建对开发的要求
- 对人力的要求
并且对于活动中会讲到的已开源搭建产品，都去试了下，以用户的角度去感受一下。
在这里，我依然以QA的方式来整理自己的收获，因为这样会更直观。（毕竟视频和文字稿后期都会整理
1. 为什么需要搭建？
这个问题很简单，都是为了避免重复性劳动，提效、赋能。
搭建的分类从用户的角度来说有两种:
- NO CODE：让运营、产品等非开发人员也能通过UI拖拽，点选的方式产出页面，直接发布。
- LOW CODE: 这次接触的一个新名词——低代码开发，简单来说是让不同水平的开发人员通过提交一些选项直接生成组件/选择模板来辅助开发完成一些复杂的应用，提升效率。
2. 搭建前后对比？
这里先消除些误区，因为搭建系统是非常消耗人力和资源的，10人团队预计一年时间才能做出雏形，如果没有合理的架构和规划是很难完成的，比如说为了做可视化而可视化搭建，很可能效率不增反减。物料难以维护、拖拽组件太丑没人用、代码生成不符合预期等等问题。
至于搭建前后服务了多少用户，效率提升了多少，这里就不给讲师们打广告了，后期ppt里都有介绍。
讲师们讲到的系统都是长时间沉淀下来的，对搭建系统中的组件、页面使用率都有数据做支撑，清楚的知道哪些组件用的频率高，生成了多少页面。那么做的时候会遇到哪些问题呢？我们继续往下看。
3. 搭建过程中遇到哪些问题，如何解决
数据
讲师们做的搭建系统应用不一样，有些是落地页，有些是多端组件、甚至还有配套编辑器等等，但是多少都避不开数据的问题，产出的静态页面、组件是不同的，数据字段怎么约束/管理。
这里有两种解决方式，一种是针对于运营使用的简单页面，可能只是改个banner、换个颜色等，可以通过搭建管理后台去配置，修改文字，链接。对于使用者的权限，也可以让管理员通过后台去配置。 另一种是异步获取的数据，需要接口请求的，可以通过协议描述符 JSON Schema 来规范前端数据类型，后端来存储。
Schema 是如何规范的呢？我们来看下洛尘的分享：
首先我们可以从业务中提炼数据
然后将数据转化为定义
再将定义规范为结构
月飞团队使用的Schema 叫做 协议标准规范，定义的更加详细，我们来看看完整的规范需要具备哪些特点：
沐童讲师（安利下这位讲师的视频，讲的非常的干）讲到的他们MPM搭建系统关于数据的一些问题：
- 请求散乱无章： 接口场景繁杂，请求难以维护
- 重复请求过多： 压垮页面性能
- 接口压力大： 同个页面多次请求同个业务接口
- 数据模型多变
- 三端同构诉求
为了解决上述问题，他们团队打造了一套高效通用的数据请求解决方案：
首先是页面模型设计
pageData 是页面的抽象描述层， pageData可以被解析成真实页面， 包括页面级配置和组件级配置
interface iPageData {
pageId: number; // 页面id
pageConfig:{ // 页面配置
basic: iBasic; // 基础信息配置
search: iSearch; // 搜索配置
share: iShare; // 分享配置
}
userConfig:{ // 用户配置
checkNewUser: boolean; // 是否需要查询新人
},
componentConfig: iComData[] // 组件配置
}
而 ComData 是 PageData的核心部分，包括了模版配置、数据配置和组件关系
接下来是数据源和数据优化策略，数据源是请求模型的基本单位，描述了一类请求动作。
高级请求模型由数据源组合而成，可以单独调用数据源，也可以调用高级请求模型。做到自由组合
请求来时，根据source标识选取数据源->实例化一个请求对象->通过请求中心去发起请求->外部服务响应后再由请求中心处理响应-> 返回处理结果-> 触发渲染
请求中心依靠一个简单的请求队列和请求缓存来避免页面发起重复请求。下面是缓存和请求队列机制图示：数据源可制定聚合分发策略，使同类请求对象在发出前经pack合并，响应后经unpack拆包分发，什么是同类请求？就是接口相同，参数不同的请求。而重复请求是接口与参数完全一致（不包括post) 。同类请求的处理过程如下：
三端同构：
如果把客户端一套照搬到直出端（SSR），可能会导致直出端拿到的页面没有数据。因为客户端的请求钩子在直出端不一定奏效。这个时候得考虑生命周期。
而同构的关键在于初态渲染（即初始状态），补充适配直出端的生命周期，三端解析流程也应统一。
MPM借鉴Nuxt.js，实现一个位于组件生命周期之前的异步函数，
每个MPM组件都有一个初态函数，初态函数以组件配置数据为入参，异步返回用于组件初始化渲染的初态数据。
三端引擎在创建组件实例前，将先收集执行各组件的初态函数。并将函数的异步返回结果作为组件初始化渲染的数据。
直出端在页面出来之后还要进行各个组件激活。（这些在Vue SSR文档有涉及
还有一个较为刁钻的场景，为了提高直出速度，可否将主次接口分开调用。在直出端调用主接口，次接口在客户端补充。
初态函数的第二个参数为一个回调函数，传入初态数据并执行可以触发引擎立即渲染，因此，利用它可以实现初态数据的分端渲染，对于这类初态函数，直出端只会响应第一个callback，余下的callback 将直接忽略。等到了客户端之后再作执行，补充动态数据。
终端秒开
墨冥团队做的搭建系统由于用于营销，所以有终端秒开的需求，我们先来看看传统的优化措施
接下来对打包的页面组成进行分析：
- Page Bundle = Page Code + Page Info + Module Code x N
- 由于Module Data 各不相同，且Module Data变更频率 > PageBundle
- 所以将Page Bundle 与 Module Data 分离，预缓存Page Bundle
- 每个Module 初始化独立异步请求 Module Data后渲染
这里有个问题是由于模块的独立性，独立异步请求数据渲染时会造成渲染的不确定性和卡顿感，
而且运营随时调整模块组合时，变更会导致预缓存频繁失效。模块的组合也是无限种的，但缓存容量有限也会有矛盾。
这里提供的优化思路是先分析不同页面，模块之间变更的优先级，先看哪些数据变更的最多!
Module Data > Page Info > Module Code > Page Code
- 对于不同页面的Page Code相同情况， 预缓存 Page Code并跨页面共享
- 对于不同页面的相同Module相同Module Code， 去缓存 Module Code并跨页面共享
- Page Info均不相同情况 聚合 Page Data = Page Info + Module Data *N
- Module Data 均不相同 分离 Page Code, Module Code, Page Data
- 在客户端容器（App） 实现页面和模块的预缓存，用户触发一定行为时触发预请求（行为包括用户下拉时去预请求，后台空闲时预请求。
流程如下图所示：
部署
洛尘他们团队使用的是鲁班系统，部署所遇到的问题是多个环境页面一样，发布会比较繁琐，最终解决是搭建生成页面，部署一次，同步三个环境。
最后一个分享奕纯大佬说的海量部署，针对商家的服务，要保证服务不能出现差错。这种情况说实话我很难遇到，而且很偏运维方向了，大家有兴趣的可以去看相关视频或者PPT。
多分支开发
iceluna 编辑器支持多分支开发，在多人并行开发过程中，甚至会有20多个分支，提交时避免不了冲突，这个情况下除了解决冲突，还提供了一个基线同步机制。代码提交发生冲突，解决之后会把冲突解决状态和带阿们备份到DB
同理，当代码需要回滚时，DB中存储的版本也需要与git仓库保持同步。
效能衡量体系
如何衡量搭建的效能提升了多少呢？iceluna 团队使用 _霍尔斯特德软件复杂度测量算法模型 _来计算预计开发时长与实际开发时长的比较。
实际开发时长包括写代码的时间和调参的时间
4. 搞搭建对开发的要求，人力要求
业务不同所需要求也是不同的，imgcook项目业务后期偏向于深度学习，当然希望前端会有这方面的能力。
综合搭建中用到的技术栈，发现vue/React + nodeJS已经是标配。人力要求的话搞搭建是非常缺人的，耗时耗力（小公司可能项目还没做出来，公司先凉了。
5. 个人思考
到第三届早早聊已经800+人参与了，虽说是线上活动，群里讨论的也非常激烈，有着线下活动没有的讨论氛围。明显感觉QA环节问的问题很多且非常有内涵。
新的名词不断的蹦出刷新我的认知，你会发现在搭建系统中，跨多端已成标配，多人协作、页面直出（SSR）、编辑器开发、深度学习、人工智能等等技术每一个都是新的领域。
分享中听到的不光是技术，还有前辈们的思考方式 他们对未来的思考，将我们的思想拔高几个level。去听听作为leader，他们的想法，或者贴近设计/产品/后端同学的方式去思考问题，毕竟在公司我们不是一个人在奋斗。这样也是更好的在工作中做到将心比心，互相理解，学习。
妙净讲师说的前端未来发展方向，将逐渐从low code向 no code过渡，变的更加智能化，「抠图仔」有可能转变为「调参工程师」，高级开发也逐渐演变为更有挑战的岗位，需要学习的还有很多。也就是说，弱者更弱，强者更强。在这不断发展的时代，你想要做哪一种呢？
