> 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-hant/2022/w35-new-understanding-of-standardization.md).

# W35-對標準化的新認知

對標準化的一些新認知。標準化工作是為系統消除差異，降低圈複雜度，讓系統變得更加可預測。

前段時間在配合微信做支付通道切換，屬於第三方支付的變更。支持過程中，在MMP場景做了一些業務的適配和收銀臺的兼容。對於前端工程來講，在系統中引入了MMP的差異化實現。帶來的直接影響就是代碼更難維護了，外部對於MMP下的收銀臺行為更加不可預測，給業務和自己留了坑，出過一個相關Case。

這裡暴露出的問題就是我們的標準化程度還不夠。如果把收銀臺的服務過程描述為一個三段式，分別為支付喚起、支付選擇與扣款、支付後處理。中間的支付選擇與扣款發生在Titans中，各端均已統一，業務差異化很少，內容雖多但可預測性好，出問題的概率也小一些。現在來看問題出現在兩頭，支付喚起和支付後處理。這兩頭應該消除端的差異，如MMP、MRN、Flutter，這些技術棧在喚起與支付後處理上應保持一致，降低收銀臺對端適配的複雜度。所以我們需要找到一個可以“掐兩頭”的好方案。

收銀臺有兩類SDK供業務選擇，一類是JS SDK，一類是Native SDK。以往我對Native SDK的認知是縮短支付喚起鏈路，提升喚起收銀臺體驗。其實並不限於此，Native SDK扮演了一個中間層的角色。通過本地化喚起與支付後邏輯，對所有技術棧提供標準支付橋，可以很好地抹平各端差異。其實是降低核心服務的圈複雜度，降低犯錯的幾率，減少事故發生。這是JS SDK難以替代的。