前言
主题与内容介绍
- 目前在做搭建系统的我，从这期以搭建为主题的《早早聊大会》收获了什么？
- 参加《早早聊大会》直播是一种怎样的体验？
本想用 “参加《早早聊大会是一种怎样的体验》”为标题，在互联网界的分享会中这真是一个长盛不衰的标题，可这期毕竟是一个线上直播形式的分享会，如果单纯以体验为主题，难免有些强差人意，更多的应该以搭建与收获为主旋律。
背景介绍
近六个月的时间一直在参与开发公司内部的业务系统可视化自动搭建平台，从0到1的实现了我们需要的功能，并用它上线了交撮、网关、日志、BFE等内部系统。我对自动搭建平台架构生疏，所以一直也在寻觅这方面的资料。
作为一个互联网从业者，不得不说掘金我是每天必去的社区，偶然中发现竟然有整整7个项目全部以搭建为主题的一期《早早聊大会》；报名之前我一直在犹豫，要不要花钱报名看直播呢？还是等后续免费的视频和资料，眼睁睁的看着早鸟票没了，在渴望了解大厂如何实现可视化搭建与Scott大神创办的《早早聊大会》究竟是怎样一个组织的双重驱动下，我还是买票了并按时参加了直播，那收获到底值不值得回门票钱呢？哈哈 继续往下看。
带着问题听直播
单正如这期《早早聊大会》的小姐姐讲师妙净所说，这类工具从来就不是什么新鲜事物。各个大厂都有自己的解决方案，一直学习页面可视化生成工具（自动搭建平台）的相关资料，其中知乎的《蚂蚁金服体验科技》专栏里有云凤蝶生成工具详细实现介绍，参加了蚂蚁金服的《第三届 SEE Conf》的《云凤蝶可视化搭建的推导与实现》、《智能可视化体系 AVA》的线上直播，受益良多却也实在不过瘾，毕竟只有2个以搭建主题的项目。
在大会前一天就迫不及待的进入直播间听Scott大神调试设备，等第二天早上醒来才知道，这位大神夜里合并了200多页讲师们要在大会上使用的PPT，并做好了当天大会的准备工作，那么我们是不是也要有所准备呢。
在这之前自己也一直在搭建工具上进行大小不一的曲折探索和尝试，也写过一些笔记和心得(按时间排序)，想来对这次大会这么翘首以盼也可能是走过的弯路所驱使。
- 记表格设计规范整理与页面可视化生成工具开发
- 再不用写查询列表页面了 | 减少低端重复劳动 vue+iview
- 开发一个前端系统生成工具的实现思路
- React无门槛实现拖拽布局、表单设计器
- 把会话放在Node层 我们这样做的很开心
对于一个在搭建系统领域的雏鸟，我有很多疑惑和问题，能从这期分享中里找到答案吗？
- 这类工具到底给谁使用？
- 必须具备哪些能力？
- 如何架构，哪些分别有哪些模块？
- 有没有健壮的开源schema协议？
- 搭建工具的未来走向哪里？
还有一个题外话，之前和我的leader也讨论过，页面数据究竟以数据的形式存在还是以代码的形式存在？这些繁杂而琐碎的小问题大厂是如何解决的呢？
第一场《如何实现PC站点搭建 | Schema》
吃过早餐我就进入直播间了，主持人和Scott在忙碌着做大会前最后的准备，由于钉钉软件投屏的使用问题，可把我们的主持人小哥哥急坏了，最后讲师一出手统统解决，原来只是个闹剧，不过主持人小哥哥责任心大大的，一直光着脚在调试，袜子都没穿，除了对主办方可靠的形象所打动，隔着麦克风都感到了一阵凉意，嘶~~。
好了，进入正题，Scott首先致辞，介绍了大会的宗旨，然后第一位讲师洛尘开始了鲁班工具的分享。
简介
鲁班可以在系统中快速建立站点应用，页面通过组件拼装上线，在分享中了解到该团队大部分项目都是同一类型项目，功能比较确定，做搭建工具也就有迹可循，以提高重复工作的效率，和我们内部开发的系统很类似，只不过我们是后台业务系统，而鲁班是类似CMS门户或者商城类应用，其中配套的有权限管理和数据统计，个人认为以应用为单位的搭建平台势必要考虑用户、权限的问题，而数据统计这个功能最大的优势则在于捎带手就能完成。
如何实现组件的属性配置
关于如何实现拼装，我们先拆分一下，应用 => 页面 => 组件 => 属性，最后就是组件的属性，属性是什么？也就是组件的props，对就是json，如何实现组件属性可配置？主要依赖 json Schema描述，洛尘详细的描述了这一部分，属性配置就是要实现一个jsonSchema规范的可视化面板，较复杂的功能点是对数组、对象类型的递归，详见PPT。
当然，属性配置是可视化的体现，在这个领域里是必须且基础的冰山一角，比如阿里的AVA图表工具就是通过算法分析数据后通过属性配置来生成图表，而真正要支撑起一套成熟的方案还有很多问题要解决，比如组件版本管理、组件依赖，静态资源的打包、不同分支环境的部署等等。
有小伙伴里提问，组件中使用了NPM的依赖怎么处理，洛尘小哥哥很负责而诚实的回答我们目前还没有做这块的处理。
部署
关于部署这部分，鲁班给出的一个很有启发性的方式，鲁班本身只是一个生成工具，它自身不应该也不需要区分环境，但鲁班可以直接将生成的项目发布到各个环境。
总结
洛尘还提出一个问题，我们把工具做成很强大势必会很复杂的工具还是一个让运营更简单更易用的工具？
根据自己在做可视化搭建工具的经验之上，又强化和加深了我对组件管理方面的理解，如组件粒度、质量、通讯方式、性能等。
第二场 《如何设计实现低代码页面搭建系统 | Paas 服务》
如果上一场分享对我而言主题是深化，那么这一场的分享对我来说就是启发性的。
初步释疑
工具是面向运营还是面向研发？我好想有了更清晰的认识，非研发人员更适合no-code，研发人员更适合low-code。 ps:单起一个小节只是为了加深自己对工具的理解；
规范 VS 生态
如果你把iceluna单纯的理解成一个页面搭建系统那你就大错特错了，iceluna要做的是一整套的搭建平台协议，统一页面搭建平台规范，孵化搭建产品，iceluna并不是一开始就有这样的雄心壮志，也是在一步步的探索和积累，时至今日已经历时3年半。诚然，再小的一个搭建平台也需要最少半年的时间做基础建设，相比于像盘散沙一样各自为阵，组建一个规范联盟不是更好吗？
比如iceluna提出的Scheam协议就应该很受重视，是很宝贵的经验财富，我们就曾遇到频繁增加和修改Scheam协议而陷入泥潭；不过目前iceluna还没开源，它的编辑器架构真是太诱人了，我们一起了解下吧？
基建狂魔
从我个人的经验来看，一个自动搭建工具要依赖很多基础建设，比如我们内部开发的工具要真正单独打包出来其实很难，用户登录需要接入SSO系统，权限管理需要接入RBAC系统，必备的OSS的文件管理能力，git仓库与分支管理、依赖运维的自动部署等等，编辑器的组件拽排版、渲染引擎、沙箱隔离、属性/事件配置、多人协作，项目维度的管理(域名、日志等)，组件维度的版本、依赖、文档等。
每一项都要耗费时间和精力，重点是这些工作并没有成熟的规范和协议，极大可能会被推翻重构或者因为错误设计而导致无法维护， 如果iceluna这样一个大厂产品致力于推动自动搭建工具的规范和提供基础设施服务，那真是一件让人欢欣鼓舞的事情。（ps：编辑器的架构不得不人想起VScode）。
霍尔斯特德软件复杂度算法模型
大厂做事就是这么有理有据有礼有节，拿出了科学指导的理论依据。实事求是的说，简单而重复的场景确实可以做到10倍甚至数十倍的提高，而方法也不一定是可视化搭建，比如复制模板同样可以达到；换言之，复杂的或者定制化要求高的工作更适合单独开发。
总结
沉浸在iceluna的启发与美好期盼中，如果成立协议委员会，多么希望加入这样的组织奉献自己的一点绵薄之力。
中场休息
转眼间已经中午12点了，上午讲师们精彩的分享真是精神上饕餮盛宴，可我的那罐哈啤却撑不起饥饿的肚皮，赶紧煮了包米线填饱肚子。
以往听老罗的演讲，主办方总要放几首撩人的歌曲，直播间里却只放了一张静态日程图片，开玩笑般在群里问了下小助手，难不成是怕出版权费？原来在中午短暂的时间，里我正狼吞虎咽时，主持人和发起人还要赶紧重启电脑，为了下午更稳定的直播，真是操碎了心呀。
第三场《如何设计实现 H5 页面搭建系统 | 数据模型》
这是一个1.9W+的页面生成工具，想必是很成熟的工具了，MPM目标很明确，运营人员使用，在排版能力上化繁为简，但并不是简单的简；MPM在性能上可谓是惊艳群芳，这场分享给我留下印象最的就是标题里4个字“数据模型”，个人认为这场分享的主题内容也就是这4个字，那到底什么意思呢？我们一起看下吧。
模板、多端、SSR
一个搭建工具的基础且必备的功能不再赘述，与其他搭建平台有差别的是自动化测试、测速，保持可靠性的容灾。另外，关于模板的概念也不太一样，依次拆分，页面 => 组件 => 模板 + 属性，而且模板和主题很类似，一个组件有多个模板，等于多个主题，另外MPM是面向多端，包括小程序、静态H5、SSR能力。
数据模型
重点来了，回到一个问题，数据模型什么意思？**对于组件拼装的展示型页面，极大概率会使请求重复、散乱，**而对于营销页面则要求更为苛刻，如何在保障多端适配、快速搭建、SSR能力的基础上再实现接口聚合呢？
MPM在这点上做的极为细腻，从组件的数据源规范、页面数据、SSR的初态函数等一系列的细节处理，听完沐童的分享，我想就MPM而言，可能没有什么词比讲师自己定义的 “数据模型” 更贴切了。
总结
现场有同学提问：同一页面同一接口的2次请求，只是参数不一样如何聚合？讲师当即做出回答：入参合并，一次请求返回2个结果；这大概就是做过与没做过的区别。
当然，这是一个对性能要求极为苛刻的解决方案，针对性较强，并不一定适合所有的页面搭建平台；但我们确实应该在网络优化方面做出一些思考，在搭建平台中如何正确的处理网络请求。
第四场 《如何为搭建物料智能生成代码| 自动编码》
首先我们应该感谢这位小姐姐讲师，听的出来妙净感冒严重，但依然坚持给我们分享，感动中。
之前道听途说过imgCook，印象中只是单纯的认为是一个PSD To html + css代码的工具，听到妙净的分享才知道自己错误的离谱，这是一个货真价实的人工智能项目。
讲师从代码生成工具的历史切入，引领我们进入更高维度的思考：智能化变革，人工智能不单单发生其他各个领域，同样发生在我们自己的编程领域。 这有助于我们理解人工智能，而不是停留在单纯的代码生成工具层面，并且阐述了nocode/autocode与lowcode的场景，更重要的是procode概念，如何人工干预生成结果，全链路监控，反向训练模型，保持imgCook的可持续正向增长。 并且iceluna和阿里大部分的搭建工具都已接入imgCook，并使用imgCookS生成组件。
imgCook不目标仅仅是把生成PSD To html+css的算法训练的更成熟，而是根据PRD和PSD直接生成业务代码， 我即看到了未来，又感到了焦虑。
总结
整个分享我都在扶着自己的下巴，防止它因为惊愕而掉在地面上，个人人为这场分享是这期大会的高潮，猛一下把同学们的思维从代码工具拉到人工智能，重新定义我们与代码的关系， 把所有人精神都抓了起来；
末尾讲师还鼓励我们，应该鼓起勇气接触和进入人工智能领域，它并没有那么吓人，讲师的团队内有很多前端工程师在慢慢转向人工智能的岗位，也使我对python产生强烈的学习意愿，不过在此之前，我想我更应该好好的了解一下openCV、tensorflow.js 等人工智能相关的知识，最后也希望pipcook能够尽早的出现在我们的工作中，进而我们可以转向更高阶层的编程工作。
结语
我沉浸在imgCook的人工智能思潮中，早已把门票的事情忘的一干二净，如果你已经被我粗浅的前4场参会笔记吊足了胃口，那么你应该如同我在报名前一样，按捺不住火热的心，迫切等待大会的录播视频和PPT，唯一的区别可能是，我当时可以报名😜，如果你在关注可视化搭建领域，我敢保证这绝对是一份值得期待的技术硬菜。
关于下篇
为了尽早分享我的收获与喜悦，我不得不将这篇笔记拆分成上下2篇，我不知道“下篇”与大会录播哪个先来，但我绝对会按照自己的方式写完下篇，那么下一篇到底有什么内容呢？
从海报中能知道，除了我鹦鹉学舌讲师们的技术硬货秒开、跨端、海量部署外，在了解到大厂搭建产品的架构后，我会更多的思考和总结自己对搭建工具的理解。
同时，我复盘了自己的参会体验，在《前端早早聊大会》如火如荼的进行时，无奈自己只能用建议的方式贡献绵薄之力，在键盘前敲出一些小而苛刻的问题和建议；但我相信，让参会同学有更好的用户体验，也是Scott的初心。
最后 给人一赞，手有余香，哈哈😸。
关于大会：前端早早聊大会目标成为用得上，听得懂，抄得走的前端大会，计划 2020 年办 12 期，由前端早早聊与掘金联合举办，未来前端早早聊大会行程动态、资料下载请扫码下方公众号跟进：
