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

# W35-Uma nova compreensão da padronização

Padronizar é eliminar diferenças, reduzir complexidade ciclomática e tornar o sistema mais previsível.

Há algum tempo, ajudamos o WeChat a trocar um canal de pagamento, uma mudança no pagamento de terceiros. Adaptamos o negócio e o checkout ao cenário MMP. Para o frontend, isso introduziu uma implementação diferente no sistema, dificultando manutenção e tornando o comportamento no MMP menos previsível para quem integra. Criamos riscos para o negócio e para nós, e houve um caso relacionado.

O problema revela padronização insuficiente. Podemos dividir o serviço do checkout em três partes: abertura, seleção e cobrança, e tratamento após o pagamento. A parte central ocorre no Titans e já é uniforme entre plataformas, com pouca variação de negócio. Tem muito conteúdo, mas é previsível e falha menos. Os problemas aparecem nas pontas. Abertura e pós-pagamento deveriam eliminar diferenças entre MMP, MRN, Flutter e outras pilhas, reduzindo a complexidade de adaptação. Precisamos de uma boa solução para controlar as duas extremidades.

Oferecemos dois tipos de SDK: JS e Native. Antes, eu via o Native SDK principalmente como forma de encurtar a abertura e melhorar a experiência. Mas ele faz mais: é uma camada intermediária. Ao localizar a lógica de abertura e pós-pagamento e oferecer uma ponte padronizada a todas as pilhas, uniformiza as diferenças. Isso reduz a complexidade ciclomática do serviço central, a chance de erro e os incidentes. É algo difícil de substituir com JS SDK.