Você pode criar um bug de propósito?

Nós, desenvolvedores, encontramos bugs regularmente, é apenas parte do nosso trabalho. Portanto, à primeira vista, a pergunta “Você pode criar um bug de propósito?” pode parecer banal - “Sim, claro, posso escrever um bug”. Porém, se você pensar bem, tudo não parece mais tão óbvio.

O fato é que bug não é o mesmo que código quebrado . Um bug é um erro, uma falha em um sistema geralmente

programa de trabalho.

Qual é o problema?

O mundo é conhecido por ser bem descrito por fórmulas matemáticas. E as fórmulas são na verdade os algoritmos. Portanto, se formos capazes de descrever matematicamente algum fenômeno, então corrigir a fórmula resultante de modo que ela apenas às vezes dê o resultado errado não é uma tarefa trivial. No entanto, não é hora de se desesperar. As condições limite podem vir a ajudar-nos aqui. Todos nós já vimos isso if index == 0 {…} else if index == n-1 {…} . Sempre há algo errado com os limites 🤷‍♀️. Então, vamos observar a primeira ideia para criar um bug - ignorar casos extremos .

Em geral, iterar através de arrays é um depósito de possíveis bugs. E o mais comum deles é o índice fora dos limites . Se você nunca se deparou com tal coisa, você nunca codificou. Infelizmente, esse bug é tão popular que as pessoas começaram a escrever wrappers seguros para arrays, algo como array[safe: index] . Então, hoje, dificilmente seus colegas aprovarão algum código sem essa coisa. Você pode tentar, mas é improvável…

Bugs predominantes incluem estouro de pilha . Um algoritmo recursivo pode ocorrer infinitamente quando não há condição de saída. A recursão parece opcional aqui - escreva while true e pronto. No entanto, mais uma vez, a popularidade do bug está jogando contra nós. Os desenvolvedores estão bem cientes dos problemas potenciais dos loops infinitos, e seus olhos certamente perceberão algo assim na revisão do código 👮

Para ainda colocar seu plano insidioso em produção, tente usar uma variável global para as condições de saída e altere-a silenciosamente de fora .

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Conselho Geral

É engraçado que até o ChatGPT se recuse a ajudar quando se trata de escrever bugs. Talvez eu só precise de uma assinatura premium… 🤔

Pelo lado positivo, a IA oferece um conjunto de regras gerais que contribuem para escrever código livre de bugs: codificar em pequenos incrementos, seguir padrões de codificação, escrever testes de unidade e bla-bla-bla. Podemos tentar fazer o oposto - escrever código espaguete e esquecer o SOLID. Porém, desta forma, perdemos o controle sobre todo o código que escrevemos. Em vez de uma arma elegante e precisa, teremos um caos incontrolável, que conquistará nosso programa.

Ao resolver o problema de criação de um bug, vale a pena determinar as subtarefas. Primeiro, precisamos encontrar alguns casos extremos raros. Em segundo lugar, precisamos disfarçar o bug como um código normal para que ele passe na revisão do código. Terceiro, temos que diminuir a atenção do departamento de controle de qualidade. Quarto, não seja pego imediatamente. Mas isso já é opcional.

Meu conselho geral é o seguinte (e você compartilha o seu nos comentários):

• Manipule o nível de acesso . Para voltar atrás, altere os valores de parâmetros importantes nos locais mais inesperados. Faça isso através de diversas aulas como se você fosse uma VPN.

• Implemente alguma lógica inesperada na classe filha. Resumindo, quebre o princípio L em SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Oculte suas mudanças insidiosas em funções maiores. Quanto mais filas, melhor - perca-se na multidão.

• Use o mesmo princípio em solicitações pull. Num PR pequeno, a probabilidade de ser notado é maior.

• Tente dividir o bug em partes e colocá-las em pull requests diferentes . Se possível, também para revisores diferentes.

• Encontre os pontos fracos do seu controle de qualidade e conquiste a confiança dele. Ou distraia-os com conversas durante a verificação.

A propósito, você já ouviu falar de Heisenbug? Este é um bug que desaparece ou muda seu comportamento durante a pesquisa/ depuração . Como o gato de Schrodinger. Perfeito se o problema de correção não for atribuído a você.

Você pode

Acredite em si mesmo! A história conhece exemplos de quando um bug foi admitido em produção em empresas muito sérias.

Voo Ariane 5 501: Um dos bugs de software mais caros ocorreu em 1996, quando o foguete Ariane 5, transportando a missão Cluster, explodiu apenas 40 segundos após a decolagem. A falha foi atribuída a um bug de software no sistema de orientação do foguete.

Mars Climate Orbiter da NASA: Em 1999, a NASA perdeu o Mars Climate Orbiter devido a um erro de software. O software usou unidades imperiais (libra-segundos) em vez de unidades métricas (newton-segundos), fazendo com que a espaçonave queimasse na atmosfera marciana.

Além disso, alguns bugs podem se tornar recursos, como o salto na parede em Mario ou o comportamento de Mahatma Gandh em Civilization …provavelmente.

Desenvolver um bug é a capacidade de pensar em seu algoritmo e antecipar completamente possíveis problemas. Portanto, mesmo que você não tenha motivos para deixar um bug no código, ainda vale a pena considerar.