Essa é uma provocação que eu criei há um tempo e, surpreendentemente, anda me ajudando muito no dia-a-dia. Mesmo quando ele não envolve programação diretamente.
Depois de consumir alguns materiais sobre ciência, deu pra entender que o cientista é basicamente uma pessoa que busca sempre provar que está errado.
A razão é simples: infinitas evidências a favor não provam que algo está certo, mas uma evidência contrária prova que algo está errado. Por isso o ideal é buscar uma evidência contrária e, na falta delas, pode-se afirmar que há uma certa probabilidade de estar certo.
Fiquei pensando porque, mesmo com testes, alguns códigos continuam cheios de bugs (meus, inclusive) e percebi que isso vem da incansável busca pelas provas a favor, nunca pelas provas contra. Isso cria um viés por vezes imperceptível.
Então eu comecei a pensar sempre em formas de provar que eu estou errado. O resultado anda bem positivo, já que eu basicamente tento tirar esse viés de achar que está certo e, por consequência, montar um teste que seja voltado a isso.
Eu sei que existem umas técnicas bem interessantes sobre testes que até permutam linhas e tal, mas é engraçado como isso se aplica até em pipelines, por exemplo. Por vezes eu me deparo com pipelines focados em fazer deploy do software e não em prever um deploy falho por natureza. Mesmo a API estando 100% coberta pelos testes, será mesmo que aqueles 15ms de tempo de resposta não seriam o bastante pra falhar o pipeline?
Ah, mas isso já existe, são testes de carga, testes de performance, testes de X…Y…Z… Mas me parece que o ponto comum em todos esses testes é de encontrar aquela evidência contra e provar que tem algo errado no código.
Talvez isso pareça um negativismo tóxico em longo prazo. Mas, se a ciência busca as evidências contrárias, por quê eu não posso buscá-las também? O interessante é que, partindo do pressuposto de que podemos estar errados, ficamos mais humildes e propensos a receber um feedback desfavorável, seja ele do teste ou de alguém do time. Dessa forma, não há negativismo e, sim, uma atitude positiva. Pense um pouco no código que testa uma funcionalidade quando o programador pensa:
a) “Como fazer agora para esse teste passar?”
b) “Como fazer agora pra provar que meu código está errado?”
E, pensando bem, esse é o centro de ideias como o Chaos Monkey. Prove que sua infraestrutura está errada.
Já faz mais de um ano que eu espalho essa ideia do “prove que você está errado” com meus colegas de trabalho e resolvi jogar essa ideia aqui. Não sei se o pessoal acaba achando legal pra não contrariar um maluco ou se realmente faz sentido em algum lugar fora da minha cabeça maluca.
Pra quem estiver interessado em ouvir um pouco sobre essa loucura, eu gravei sobre isso aqui.
Abraços!
Ataxexe
