文章目录
tips:文档会继续完善,也欢迎读者评论补充完善
一、什么是预览,什么场景需要预览
1. 预览功能介绍
预览主要指的是:用户配置之后,可以先在配置生效前,去配置生效的地方看看效果,如果确认ok之后,再将配置生效。
比如:我现在在后台配置某个app的开屏动画,配置好之后,我可以现在app上预览下,如果存在问题,比如没展示出来、某些机型不适配之类的,我可以再修改,直到合格之后再正式发布上线。
2. 预览应用场景
给公司外部用户或者公司内部重要用户使用的产品,需要人工做配置的情况。
如果是内部不重要用户(卑微打工人)使用的功能,那直接配置后生效就行了,反正配置出错的后果也不严重,改过来就是了。
二、预览功能的作用
1. 预防配置出错
这里主要是预防配置出现错误,在无法看到具体效果的情况下,无法及时感知到。
比如本来应该给配置A,不小心配置成了B。
2.相关功能的常态巡检
这个其实是在用配置人员做一个线上功能是否正常的常态巡检了。配置人员预览之后,确认ok,那至少对于这份配置来说,在线上是正常的。
在真实的生产环境,各种稀奇古怪的问题都可能出现,比如:
- 前端大整数误差
- 之前配置的A、B、C都没问题,配置D就出问题了
- 别人加了个拦截器啥的,影响到我们的功能了
- 。。。。。
三、预览功能应该如何做
要素解析:
- 预览通过后,用户回到配置端,点击发布时:
- 检查配置是否被预览过:
- 避免用户预览是出现遗漏,导致有配置没有被预览到
- 避免用户太过自信,不去实际执行预览而直接发布
- 按照规则检查配置是否正常
这个是给用户做的最后的兜底,如果存在不合法的配置,但是用户没发现,就要靠着最后一步检查来兜底。
- 检查配置是否被预览过:
三、常见问题
1. 为什么不能在填写配置的地方,直接模拟下配置生效端的效果?
先说结论:在配置端模拟配置生效端做预览,是个耗时耗力、后患无穷、又没啥用的操作。
原因如下:
- 配置生效端的页面逻辑做了变化,在配置端如何感知到这个事情并及时更新?
- 以后配置生效端页面逻辑的所有变化,都要做双份修改,这个工作量成本能否承受?
- 配置生效端与配置端,毕竟是两个平台,无法完全模拟。
比如配置端是内部网页,生效端是app,网页和app的跨端差异本来就很大,而且app端可能有风控、安全、审核等各种逻辑在,这个难道网页端也能模拟?
既然无法完全模拟,那么这个预览理论上就是有漏洞的。我们做预览的两个目的就无法达到:预防配置出错、相关功能的常态巡检。
那么配置生效端做预览,优势在哪儿呢?
- 预览正确性有保证。
在配置生效端预览的效果,就是最终生效的效果。我们预览没问题,那么上线就一定也是没问题的 - 工作量成本低,且无后患
在填写配置端:需要做好已上线版本与未上线版本数据的维护、预览信息的维护
在配置生效端:只需要判断当前用户是否预览,然后根据情况返回已上线版本数据或者未上线版本数据即可
2. 作为开发人员,我们为什么要坚持做预览功能?
- 公司对技术人员的要求
假如发生了可以通过预览去避免的异常,在技术要求很严格的公司,比如拼多多,一个事故原本可以通过设计更好的方案来避免,但是却没有做,那么开发是得担责的;在技术要求不那么严格的公司,那当然是谁负责的那块出问题谁背锅了。 - 如果是运营配置出错,但是运营没有发现问题
这个时候不还是得需要开发来排查?
如果是很紧急的线上问题,可能半夜还得把你叫起来解决。半夜叫起来还算好的,如果没把你叫起来,时间拖得长了,小事故变成大事故,即使一开始不是你的责任,因为没有及时相应解决,你的锅也背定了。
咱们作为技术开发人员,肯定是不希望承受这种无妄之灾的。 - 运营配置没出错,是运营配置的数据正好触发了我们的隐藏bug
淦,这种情况更要命了,这妥妥的是开发的责任了。
如果有预览,运营去线上看一眼,发现这个配置会导致出错,然后通知我们开发去把bug修了。既避免了我们开发去背锅,而且别人还得称赞一句:嗯,这开发技术方案设计很严谨,不错。
看完上面的分析,发现华点了吗?
不做预览,出锅之后,忙的鸡飞狗跳的是运营和开发,要背锅的是运营或者开发,都和产品没关系。产品只需要保证自己的产品设计达到目的就算完成任务了。
很多开发认为,增加预览功能,加了工作量,只是为运营兜底不出错,这么舍己为人划不着。实际上,咱们开发和运营才是一条绳上的蚂蚱呀。