> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2022-nian/w35-dui-biao-zhun-hua-de-xin-ren-zhi.md).

# W35-对标准化的新认知

对标准化的一些新认知。标准化工作是为系统消除差异，降低圈复杂度，让系统变得更加可预测。

前段时间在配合微信做支付通道切换，属于第三方支付的变更。支持过程中，在MMP场景做了一些业务的适配和收银台的兼容。对于前端工程来讲，在系统中引入了MMP的差异化实现。带来的直接影响就是代码更难维护了，外部对于MMP下的收银台行为更加不可预测，给业务和自己留了坑，出过一个相关Case。

这里暴露出的问题就是我们的标准化程度还不够。如果把收银台的服务过程描述为一个三段式，分别为支付唤起、支付选择与扣款、支付后处理。中间的支付选择与扣款发生在Titans中，各端均已统一，业务差异化很少，内容虽多但可预测性好，出问题的概率也小一些。现在来看问题出现在两头，支付唤起和支付后处理。这两头应该消除端的差异，如MMP、MRN、Flutter，这些技术栈在唤起与支付后处理上应保持一致，降低收银台对端适配的复杂度。所以我们需要找到一个可以“掐两头”的好方案。

收银台有两类SDK供业务选择，一类是JS SDK，一类是Native SDK。以往我对Native SDK的认知是缩短支付唤起链路，提升唤起收银台体验。其实并不限于此，Native SDK扮演了一个中间层的角色。通过本地化唤起与支付后逻辑，对所有技术栈提供标准支付桥，可以很好地抹平各端差异。其实是降低核心服务的圈复杂度，降低犯错的几率，减少事故发生。这是JS SDK难以替代的。