Hellooo-Joy

时间还没到期，先把问题1和3回答一下吧，问题2还要再琢磨一下 Q1. 根据你的描述：“通过拖拽配置控件自动实现一个自定义表单”，以及 “公司部门开发间业务比较封闭，各自完成自身业务为主”。业界公开的拖拽方案比较多，因为更容易产生宣讲效果。请你思考一下，你为什么当时选择拖拽形式来做这样的表单？目前从公司情况来看并不理想，现在应该如何改进？ A 1. 拖拽的做法：实际上是为了更好的交互，控件拖拽进入表单里，在排序上，操作上也更加友好 2. 不理想原因：第一、公司各个部门业务各自为王，可能难以推广，这个虽然不能算是原因可确实有这样的客观因素；第二、从部门组内使用上看，业务场景比较复杂，比如会出现各个控件数据联动、控件选项值服务端实时调用、权限等问题，这些问题虽然有通过方案解决，但在使用上还是比较繁琐的；第三、为了减轻某些复杂控件开发人员的负担，我们开放两个控件，第一个控件业务方可以根据自己的需求通过slot方案在表单中开发添加自己的方案，第二个方案一个在线编辑平台，业务方可以提交自己在线编辑的控件。 Q3. 描述数据采集链路(如果数据是目前公司自己采集的)，ETL，BI，最后落到前端开发工作的流程，举一个典型的业务场景例子来说明整个数据链路，并谈谈你认为前端在这个过程中的价值。 A 1. 流程：qian d前端开发内容为web标注  2. 场景：爬公众号文章，先爬虫爬取页面，因为存在更新，所以会定时跑任务爬取，爬取后的页面进行解析，解析成可以解析的一切字段，然后对字段内容的数据进行清洗入库，这个库是个总库，包含一切来源的所有数据；接下来不同的业务有不同的业务规则获取数据，如果有数据错误的情况，算法可进行校验后可重新打日志进行入库。 3. 前端的价值：第一是透明化，数据可查，哪个环节出错一眼可见；第二可视化，数据量情况一眼可见，例如数据图表统计；第三是规则存储，存储各个数据解析阶段的规则；最后也是最无奈的一点，数据的采集也不是完全正确的，开发人工校验平台。

> 拖拽的做法：实际上是为了更好的交互，控件拖拽进入表单里，在排序上，操作上也更加友好 空闲时间，就问题一想和老师交流一下；老师厉害，一眼就道明了我们之前的问题和困惑。 背景：之前这个表单编辑器就是希望给用户用的，所以拖拽的考虑是合理的。但是在实现用户基本功能后发现很多配置操作是非开发用户难以完成的，比如联动需要调用远程接口，接口地址配置，表单编辑器字段与业务字段匹配的配置，等等问题。所以我们新增一个路由作为开发人员入口，这些配置可以通过开发人员的入口进入完成。 所以现在的结果是：简单表单可以通过非开发人员进行配置；复杂表单就需要开发人员介入了；如果是特别复杂的，我也提过，在业务中引入表单这个组件的时候可以在slot内自己完成自己的组件。目前的做法是这样，我其实也特别想和老师交流一下，有没有了解过这方面更优的做法，给些启示，谢谢🙏