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

# W35-Ein neues Verständnis von Standardisierung

Einige neue Einsichten zur Standardisierung. Sie beseitigt Unterschiede im System, senkt seine zyklomatische Komplexität und macht sein Verhalten vorhersagbarer.

Vor einiger Zeit unterstützten wir WeChat bei einem Wechsel des Zahlungskanals, also einer Änderung beim externen Zahlungsanbieter. Dafür passten wir Geschäftsfunktionen und Checkout-Kompatibilität im MMP-Szenario an. Aus Frontend-Sicht führten wir damit eine besondere MMP-Implementierung ins System ein. Der Code wurde unmittelbar schwerer wartbar. Außenstehende konnten das Verhalten des Checkouts unter MMP schlechter vorhersagen. Wir schufen Fallstricke für Geschäftsbereiche und uns selbst; ein entsprechender Vorfall trat bereits auf.

Darin zeigt sich unzureichende Standardisierung. Der Checkout-Dienst lässt sich in drei Phasen beschreiben: Zahlung aufrufen, Zahlungsart auswählen und abbuchen, anschließend nachbearbeiten. Die mittlere Phase läuft in Titans und ist über die Plattformen hinweg bereits vereinheitlicht. Es gibt wenig geschäftliche Unterschiede. Trotz des großen Funktionsumfangs ist sie gut vorhersagbar und weniger fehleranfällig. Die Probleme liegen heute an beiden Enden, beim Aufruf und bei der Nachbearbeitung. Dort sollten Plattformunterschiede verschwinden. MMP, MRN und Flutter sollten sich in diesen Schritten gleich verhalten, damit der Checkout weniger Anpassungslogik benötigt. Wir brauchen also einen guten Ansatz, der beide Enden vereinheitlicht.

Geschäftsbereiche können zwischen JS-SDK und Native-SDK wählen. Früher sah ich den Nutzen des Native-SDK darin, den Aufrufweg zu verkürzen und den Checkout schneller zu öffnen. Seine Rolle reicht weiter. Es ist eine Zwischenschicht. Indem es Aufruf und Nachbearbeitung nativ übernimmt und allen Stacks eine standardisierte Zahlungsbrücke anbietet, kann es Plattformunterschiede gut ausgleichen. Damit sinken die zyklomatische Komplexität des Kerndienstes, die Fehlerwahrscheinlichkeit und die Zahl der Vorfälle. Das kann ein JS-SDK nur schwer ersetzen.