Poka-Yoke: Prevenção de Erros para Software

A ideia de Shigeo Shingo, do Sistema Toyota de Produção: as pessoas sempre cometerão erros; esse não é o problema que vale a pena resolver. O problema é permitir que um erro se torne um defeito. Então, você para de tentar tornar os humanos mais cuidadosos e começa a redesenhar o trabalho para que o erro não possa acontecer fisicamente ou se anuncie imediatamente.

Um poka-yoke ("poh-kah yoh-kay", ポカヨケ) é um dispositivo: um gabarito, uma forma, um contador; não uma instrução. Em software: um tipo, uma restrição, um hook, um esquema, uma máquina de estados. A consequência mais importante:

Um comentário, uma docstring, uma página wiki, uma lista de verificação de revisão de código ou uma linha em CLAUDE.md dizendo "não faça X" não é um poka-yoke. É treinamento. O treinamento se degrada. Um dispositivo não. Se sua correção proposta depende de alguém se lembrar de algo, continue.

Quando Usar Esta Habilidade

• Use quando o usuário disser "poka-yoke isso", "previna erros nisso" ou "torne isso mais difícil de fazer errado".
• Use ao projetar uma interface, esquema ou máquina de estados e a solicitação for "torne estados inválidos irrepresentáveis" ou "para que os chamadores não possam estragar tudo".
• Use ao auditar código existente em busca de "armadilhas": "o que pode nos prejudicar aqui", "o que é fácil de usar incorretamente".
• Use após um incidente, quando a correção deve fechar a classe em vez do caso: "certifique-se de que isso nunca mais aconteça", "esta é a terceira vez".
• Especialmente para dinheiro, autenticação, permissões, exclusão, migrações e pipelines, onde a falha é silenciosa.

Os dois eixos

Todo poka-yoke real responde a duas perguntas. Use ambos ao classificar um perigo ou propor um dispositivo. Eles são a diferença entre este método e a revisão de código genérica.

Eixo 1, Função regulatória: o que acontece quando o erro ocorre?

Esta é uma escada de preferência rigorosa. Sempre busque o degrau mais alto que você puder pagar.

Regra de Shingo: prefira controle sobre aviso, sempre, e só se contente com aviso quando o controle for genuinamente muito caro, então diga por que em voz alta. Em software, a razão honesta geralmente é "a linguagem não consegue expressar" ou "quebraria todos os chamadores existentes", e ambos valem a pena ser declarados explicitamente para que a troca seja visível.

Eixo 2, Função de configuração: como o dispositivo percebe?

Os três métodos de detecção de Shingo se mapeiam claramente para o software. Estas são suas lentes de inspeção, execute as três em qualquer interface e você encontrará perigos que uma revisão de código geral não encontra.

O terceiro princípio: inspecionar na origem

Shingo separou a inspeção de origem da inspeção informativa, que encontra o defeito

…