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

# W35-Una nueva forma de entender la estandarización

Algunas ideas nuevas sobre la estandarización. Estandarizar consiste en eliminar diferencias de un sistema, reducir su complejidad ciclomática y hacerlo más predecible.

Hace poco colaboramos con WeChat en un cambio de canal de pago, una modificación en los pagos de terceros. Durante el trabajo, hicimos algunas adaptaciones del negocio y del checkout para el entorno MMP. Desde el punto de vista de la ingeniería frontend, introdujimos una implementación específica para MMP dentro del sistema. La consecuencia directa fue un código más difícil de mantener. Para quienes lo utilizan desde fuera, el comportamiento del checkout en MMP se volvió menos predecible. Dejamos riesgos tanto para el negocio como para nosotros mismos, y ya se produjo un caso relacionado.

Esto revela que nuestro grado de estandarización sigue siendo insuficiente. Podemos describir el servicio del checkout en tres etapas: invocación del pago, selección del método y cargo, y procesamiento posterior al pago. La etapa intermedia ocurre dentro de Titans y ya está unificada entre clientes. Tiene pocas diferencias de negocio y, aunque contiene muchas funciones, es bastante predecible y menos propensa a fallos. Ahora vemos que los problemas están en los dos extremos: la invocación y el procesamiento posterior. En ellos deberíamos eliminar las diferencias entre tecnologías como MMP, MRN y Flutter. Todas deberían comportarse de forma uniforme al iniciar y terminar el pago para reducir la complejidad de adaptar el checkout a cada cliente. Necesitamos, por tanto, una buena solución para controlar esos dos extremos.

Los equipos de negocio pueden elegir entre dos clases de SDK del checkout: el SDK de JS y el SDK nativo. Antes entendía que el SDK nativo servía para acortar la cadena de invocación del pago y mejorar la experiencia de apertura del checkout. Pero su función no termina ahí. Actúa como una capa intermedia. Al llevar a código nativo la invocación y la lógica posterior al pago, ofrece un puente de pagos estándar para todas las tecnologías y elimina buena parte de sus diferencias. En realidad, reduce la complejidad ciclomática del servicio central, la probabilidad de equivocarse y el número de incidentes. Es una función que al SDK de JS le resulta difícil sustituir.