预览应该怎么做？

tips：文档会继续完善，也欢迎读者评论补充完善

一、什么是预览，什么场景需要预览

1. 预览功能介绍

预览主要指的是：用户配置之后，可以先在配置生效前，去配置生效的地方看看效果，如果确认ok之后，再将配置生效。
比如：我现在在后台配置某个app的开屏动画，配置好之后，我可以现在app上预览下，如果存在问题，比如没展示出来、某些机型不适配之类的，我可以再修改，直到合格之后再正式发布上线。

2. 预览应用场景

给公司外部用户或者公司内部重要用户使用的产品，需要人工做配置的情况。
如果是内部不重要用户（卑微打工人）使用的功能，那直接配置后生效就行了，反正配置出错的后果也不严重，改过来就是了。

二、预览功能的作用

1. 预防配置出错

这里主要是预防配置出现错误，在无法看到具体效果的情况下，无法及时感知到。
比如本来应该给配置A，不小心配置成了B。

2.相关功能的常态巡检

这个其实是在用配置人员做一个线上功能是否正常的常态巡检了。配置人员预览之后，确认ok，那至少对于这份配置来说，在线上是正常的。
在真实的生产环境，各种稀奇古怪的问题都可能出现，比如：

• 前端大整数误差
• 之前配置的A、B、C都没问题，配置D就出问题了
• 别人加了个拦截器啥的，影响到我们的功能了
• 。。。。。

三、预览功能应该如何做

要素解析：

1. 预览通过后，用户回到配置端，点击发布时：
   • 检查配置是否被预览过：
     • 避免用户预览是出现遗漏，导致有配置没有被预览到
     • 避免用户太过自信，不去实际执行预览而直接发布
   • 按照规则检查配置是否正常
     这个是给用户做的最后的兜底，如果存在不合法的配置，但是用户没发现，就要靠着最后一步检查来兜底。

三、常见问题

1. 为什么不能在填写配置的地方，直接模拟下配置生效端的效果？

先说结论：在配置端模拟配置生效端做预览，是个耗时耗力、后患无穷、又没啥用的操作。
原因如下：

1. 配置生效端的页面逻辑做了变化，在配置端如何感知到这个事情并及时更新？
2. 以后配置生效端页面逻辑的所有变化，都要做双份修改，这个工作量成本能否承受？
3. 配置生效端与配置端，毕竟是两个平台，无法完全模拟。
   比如配置端是内部网页，生效端是app，网页和app的跨端差异本来就很大，而且app端可能有风控、安全、审核等各种逻辑在，这个难道网页端也能模拟？
   既然无法完全模拟，那么这个预览理论上就是有漏洞的。我们做预览的两个目的就无法达到：预防配置出错、相关功能的常态巡检。

那么配置生效端做预览，优势在哪儿呢？

1. 预览正确性有保证。
   在配置生效端预览的效果，就是最终生效的效果。我们预览没问题，那么上线就一定也是没问题的
2. 工作量成本低，且无后患
   在填写配置端：需要做好已上线版本与未上线版本数据的维护、预览信息的维护
   在配置生效端：只需要判断当前用户是否预览，然后根据情况返回已上线版本数据或者未上线版本数据即可

2. 作为开发人员，我们为什么要坚持做预览功能？

1. 公司对技术人员的要求
   假如发生了可以通过预览去避免的异常，在技术要求很严格的公司，比如拼多多，一个事故原本可以通过设计更好的方案来避免，但是却没有做，那么开发是得担责的；在技术要求不那么严格的公司，那当然是谁负责的那块出问题谁背锅了。
2. 如果是运营配置出错，但是运营没有发现问题
   这个时候不还是得需要开发来排查？
   如果是很紧急的线上问题，可能半夜还得把你叫起来解决。半夜叫起来还算好的，如果没把你叫起来，时间拖得长了，小事故变成大事故，即使一开始不是你的责任，因为没有及时相应解决，你的锅也背定了。
   咱们作为技术开发人员，肯定是不希望承受这种无妄之灾的。
3. 运营配置没出错，是运营配置的数据正好触发了我们的隐藏bug
   淦，这种情况更要命了，这妥妥的是开发的责任了。
   如果有预览，运营去线上看一眼，发现这个配置会导致出错，然后通知我们开发去把bug修了。既避免了我们开发去背锅，而且别人还得称赞一句：嗯，这开发技术方案设计很严谨，不错。

看完上面的分析，发现华点了吗？
不做预览，出锅之后，忙的鸡飞狗跳的是运营和开发，要背锅的是运营或者开发，都和产品没关系。产品只需要保证自己的产品设计达到目的就算完成任务了。

很多开发认为，增加预览功能，加了工作量，只是为运营兜底不出错，这么舍己为人划不着。实际上，咱们开发和运营才是一条绳上的蚂蚱呀。