W35 - New Understanding of Standardization

Some new insights on standardization. Standardization work aims to eliminate differences across systems, reduce the system’s cyclomatic complexity, and make the system more predictable.

Recently I coordinated with WeChat to switch payment channels, which involved changes to a third-party payment provider. During support we implemented some business adaptations and cashier compatibility for the MMP scenario. For front-end engineering, this introduced an MMP-specific implementation in the system. The direct impact was that the code became harder to maintain; external behavior of the cashier under MMP became less predictable, leaving pitfalls for both the business and ourselves, and a related case occurred.

This exposes that our level of standardization is still insufficient. If we describe the cashier’s service process as three stages—payment invocation, payment selection and deduction, and post-payment processing—the payment selection and deduction occur within Titans, where all clients are already unified. There is little business variability there; although the content is extensive, its predictability is good and the chance of issues is lower. The problems now appear at both ends: payment invocation and post-payment processing. Those two ends should eliminate client differences—MMP, MRN, Flutter and similar stacks should behave consistently in invocation and post-payment handling to reduce the complexity of client-side adaptations for the cashier. So we need to find a good solution that “pinches both ends.”

The cashier offers two types of SDKs for businesses to choose from: a JS SDK and a Native SDK. My previous understanding of the Native SDK was that it shortens the payment invocation path and improves the cashier launch experience. In fact, it does more: the Native SDK plays an intermediary role. By localizing invocation and post-payment logic and providing a standard payment bridge to all stacks, it can effectively smooth out cross-client differences. This reduces the cyclomatic complexity of core services, lowers the likelihood of mistakes, and reduces incidents. This is something the JS SDK struggles to replace.