vianvio
vianvio
Q1不要局限于前端，把视野放宽，尽可能去多了解。
架构图画的太粗略了，架构图是要让别人看完能落地的，不是空洞的关键字罗列，现在这个图谁都能画，但是没办法落地。 Q3不是概念性的回答，而是实际落地方案，只是理念大家都知道的 Q4指的是内容可复用性，平台化方案
> 1-b：线上发布规范我认为可以分为三个阶段，发布前，发布中和发布后 1-a的问题通过规范还是可以接受的，毕竟是一个主观性比较多的问题，但是这个问题是可以有一些系统流程来保障的，文档约束这些都是受每个人自觉性驱动的，对于稳定性来说，一定要可以确定并且可执行的硬性方案来保障。 > 1-c：首先，我们在项目初始阶段，做好全局错误监听工程，这里可以接入阿里云的日志服务，把前端出现的任何异常，上报至阿里云，通过查找日志，基本上可以定位绝大部分的错误。定位到问题点的之后，安排成员从发布分支切热修复分支修复问题，安排测试人员测试问题是否修复，确保修复完毕之后，再次选择增量发布该模块 能否自动告警？能否1分钟定位问题，15分钟内解决？这几个问题都是可以沉淀出一套监控系统的，可以思考一下。 flutter方面接触不多，没法给到参考，抱歉啦
Q2的思路挺好，可以试着做一个类似的脚手架仓库出来，一点点积累起来，自然就有技术沉淀了
上面都是流程图，不是技术架构图，需要重新画一下。不过基于上面的图对流程大概有一些了解了，架构图画的时候要将服务端部分细化，而不是两个小框的模糊说明，不明白的地方去百度搜索或者问服务端的同学
> 2.同一套方案如何在新的页面复用？能否做到代码无侵入？ > 答：以农险为例，投保、核保、批改三种情况下，保单页面大同小异，可将公共部分提取出来封装成公共组件common.vue。然后在不同场景下的页面分别引入common.vue,并将保单数据通过props传入，不同的功能则在组件标签外编写或者通过slot标签插入。这样做的好处是可以多处复用，公共组件只会根据不同的数据来做对应处理，并且能保证引入之后不会被改变。 这里的问题是上面的abtest能否无侵入的复用哈
> 4.用户发现当前页面某个按钮看不到，如何判断出来是因为代码报错导致，还是权限控制导致？ > 答：这个问题不是很理解，好像没遇到过类似的情况。js执行报错会上传错误信息，其余的都可以认为是权限控制导致看不到某按钮。 比如权限叠加的算法出现问题，这时候如何判断是配错了，还是代码出问题了？另外，核心是用户只会反馈说按钮看不到了，如何基于有限的信息输入，来定位看不见按钮的原因？
Q1的图画的非常好，结构清晰。为什么有rc组件这部分再去看一些博客，有必要再思考一下。 Q2的目的是希望反思组件库的价值，因为大部分情况大家会因为组件库的概念而去做组件库，或者换一个说法为了复用而复用，虽然对于单一项目来说，能抽离总是好的，但是这里是希望能去细想一下，我为什么要复用，哪些地方应该再抽象一层。想明白之后，或许对Q1为什么有rc会有感觉。 Q3技能图谱太过简略了，所以这里的打分都不靠谱，打分本身不是目的，而是看你能否看清楚自己的能力，能拆解到多细本身也是一种熟练度的表现。
那就必须得是精品啦
> 拖拽的做法：实际上是为了更好的交互，控件拖拽进入表单里，在排序上，操作上也更加友好 从交互的角度确实如你所说的这样，但是请思考一下组件的用户群体，是以开发为主，还是以非开发的角色为主，再回来看拖拽的合理性。同时，基于用户群体，思考另一个问题，拖拽的结果核心是界面，还是代码，反推表单实现上是否会有不同。 > 问题3 流程非常清晰，感谢分享 > 问题3拓展 根据目前的业务形态，整个数据分析应该是离线完成的？那么抛开目前业务来看，流程上哪里可以做些改动来满足实时分析？