这一期的大会，与上一届再续前缘，那么这一篇文章也就继续跟，然而跟不上。
回顾一下，上一届主要以基建为主，如何去进行实施基建工程，需要哪一类人去引领基建的起始，怎么去分配时间？对技术能力的要求等等。
一直在思考的一个问题，如何应用到实际的事件中去，这次的会议听完，实际上看了两三遍，有些还是觉得很有难度，不是一般的有难度。
可以继续思考几个问题
可以用到哪些技术？
编写组建可以使用 JSON Schema 作为数据结构规范，那么技术框架就可以选定为：
vue + element ui + koa + node + schema
组件搭建过程？
组件管理通过版本号、来源进行管理；
通过Schema定义组件数据结构规范，在输出时进行判断
数据如何处理？
总结在最后
JSON Schema
新名词。 主要是JSON的约束，把定义规范制作成结构。
Schema 可以带来什么好处呢？
好处就是规划数据、类型，灵活度高，自由组合搭配。跟七巧板一样。
可以用来规范 API 数据、组件等等。
作者：洛尘 | 技术一小步，业务一大步
组件中的数据包含静态数据，一个是动态数据
静态数据主要来源运营人员；动态数据来源API请求
小小笔记
基础设施方向
- 描述协议 - 标准规范
- 低代码 - 开发生态
- 低代码 - 多端适配
- 低代码 - 核心能力
- 插件生态 & 物料生态
衡量体系标准
霍尔斯特德软件复杂度测量算法模型
计算公式
研发效能 = 预计开发时长/实际开发时长
请求模型
量化请求，在进行组合
数据源是基本单位，描述一类下的请求动作
作者：沐童
重复请求的问题
通过请求队列与缓存解决
作者：沐童
传统优化-最佳实践
作者：墨冥
总结：
每个人在开发的过程中需要不断思考与抽象，在开发过程中，开发完一个项目回过头看看有哪些是可以抽象出来，形成自己知识体系，还有积累自己的函数库、组件库；
在团队中，与前端同学共同交流是否可以搭建一个自己的小知识库，在这次分享中也提及过，基建可大可小，重在解决实际需求痛点。在服务自己的通过也可以服务他人。
这次的分享最大的收获就是思路，具体的实践、技术还是需要自己去探索实现。
最后分享一下自己做的一件事情，做一个集成化平台，打通需求的诞生到项目落地部署整个链路；打算先开源整个思路，后面开源整个系统
主要分为九大块：需求管理、文档管理、设计中心、任务、测试计划、API协作、Bug记录、版本迭代管理、实施部署。
设想：
需求管理主要包含
需求来源统一，包含一个门户反馈，门户反馈绑定到项目或产品；（小的门户反馈已完成发布，效果还可以，后面将门户反馈集成到产品中去。）
在项目管理后台查看查看需求的数据，并对需求进行反馈，与研发、销售、用户链路打通。（目前可以查看所有集中反馈的需求，即将实现在用户端能够查看到我方的反馈，是否响应以及回复情况，以及研发反馈与销售市场的反馈，打通这中间的协作沟通）
需求分析，这个主要针对各系统、各方面来源的需求进行分析；（还没有做，优先级不高，前面是目前遇到的小需求，就先做了）
文档编写协作包含
技术规范、设计体系规范、项目资料、流程资料等等
说明书在线编制发布到对应的系统，统一所有说明书的管理更新升级。（已经实现，但是需要进行优化）
设计主要包含
每个产品或者项目，设计人员可以直接导出html，上传到系统中，系统自动创建站点进行访问，可以绑定到项目与产品。还要原型
API协作
后端开发人员可以通过 swagger直接导出，那么找了目前开源的框架，最终选取 YAPI 开源框架，目前做集成（但是还没有集成），内部用户已经打通。在项目管理系统里面可以对第三方系统进行管理和用户管理。
由于前端操作体验不符合目前的需求，比如 yapi 不支持树结构、操作层面会有困扰等等，将重新设计改造。（正在进行中）
其他的现在就不写了，在做的过程中，可以抽离出组件进行集中管理，也就是物料中心。从身边的小需求做起，先解决协作方式，在定义好设计规范等等。
深入浅出，长路慢走。
