Imagine o seguinte cenário:

Você detectou que seu programa (ou de outra pessoa) possui um erro - uma função produz o resultado errado quando recebe uma entrada específica. Você examina o código e não consegue encontrar nada de errado: ele parece esbarrar quando recebe essa entrada.

Agora você pode fazer uma de duas coisas: você pode examinar o código mais profundamente até encontrar a causa real; ou você coloca um curativo adicionando uma ifinstrução que verifica se a entrada é essa entrada específica - se for, retorne o valor esperado.

Para mim, aplicar o curativo seria completamente inaceitável. Se o código estiver se comportando de maneira inesperada nessa entrada, a qual outra entrada que você perdeu, ele reagirá estranhamente? Simplesmente não parece uma solução - você está apenas colocando o problema debaixo do tapete.

Como eu nem consideraria fazer isso, fico surpreso com a frequência com que os professores e os livros nos lembram sobre como aplicar correções de "bandagem" não é uma boa idéia. Então, isso me faz pensar: quão comuns são esses tipos de "correções"?

As pressões de tempo / prazo são um dos motivos.

Se você estiver enfrentando um prazo apertado e seu chefe estiver respirando pelo pescoço (possivelmente literalmente!), Faça isso e pense "Vou voltar e consertar isso mais tarde" é muito tentador e pode ser a única coisa que você pode fazer.

É claro que o número de vezes que você realmente volta e corrige corretamente é muito pequeno e distante, porque você tem um novo problema que precisa ser corrigido ontem.

Por mais que nós, programadores, não gostemos de admitir, um software lindamente codificado nem sempre se traduz em mais valor para a empresa ou para os clientes. Isso é duplamente verdadeiro em uma situação de desastre, por exemplo, o software cobra duas vezes o cartão de crédito das pessoas. Às vezes, como um curativo, você só precisa interromper o sangramento por qualquer meio necessário e prometer voltar depois que o paciente tiver sido estabilizado e realmente resolver o problema principal.

O truque é que, uma vez perdida a urgência, é realmente difícil convencer alguém a priorizar a substituição do curativo por uma correção verdadeira. Especialmente considerando que sempre há outra questão urgente esperando na fila atrás da primeira. Você só precisa estar atento para ficar com o problema além da solução rápida.

Tempo

É a razão número 1 na minha opinião. Embora se o problema for de base de código, talvez eu leve mais tempo para investigá-lo. Muitas vezes, minhas correções de "bandagem" envolvem ajustes de CSS ou UI. Eu escrevi CSS e JavaScript embutidos bastante desagradáveis ​​para lidar com eles rapidamente. Voltar e consertá-lo é sempre uma opção, se você tiver tempo.

Nós os fazemos excepcionalmente.

Para correções durante o desenvolvimento, garantimos que nenhuma correção seja feita sem conhecer a causa raiz. Contudo:

• Excepcionalmente, a pesquisa da causa raiz começará a demorar demais ou será interrompida E há um prazo difícil,
• Excepcionalmente, alterações no código para corrigir a causa raiz não são taticamente viáveis ​​(a mudança levará muito tempo e o prazo se aproxima)

Nesses casos, optamos por correções de "bandagem". Em seguida, abrimos os defeitos internos para solucionar a causa raiz. Sim, na maioria das vezes esses defeitos internos são tratados com muito baixa prioridade.

Para correções no fluxo de manutenção, garantimos que nenhuma correção seja feita sem conhecer a causa raiz. Contudo:

• Muito excepcionalmente, a pesquisa da causa raiz será interrompida,
• Excepcionalmente, pode ocorrer que a correção da causa raiz seja taticamente inviável (a mudança não é trivial e o cliente precisou da correção ontem).

Nesses casos, optamos pela correção temporária de "curativo" primeiro e, quando o cliente fica satisfeito, trabalhamos na correção adequada e somente então o defeito é resolvido.

Desambiguação.

• Dado um bug específico, há uma dificuldade considerável em definir objetivamente se uma correção específica é um "curativo" porque: a "solução correta" de uma pessoa pode ser a "bandagem" de outra pessoa.
• Portanto, uso a seguinte definição: para corrigir um defeito de uma maneira menos elegante e menos bem estudada do que eu gostaria de ter feito profissionalmente.

Primeiro, com relação à frequência das correções "curativas":

• Novo código: quase nenhum.
• Código antigo:
  • Você encontrará alguns, embora geralmente sejam escritos com elegância suficiente (consulte "mitigação orientada a dados" abaixo) para que não pareçam bandagens e sobrevivam a todas as revisões de código.
  • Preste atenção também ao "curativo invisível": simplesmente não chame essa função. Com a falta de código, não há nem um indício de que exista um bug.
• Código antigo com muitas dependências externas:
  • Quase cheio disso.
  • Quase sempre foi escrito para uma versão obsoleta da dependência, e ninguém realmente leu as "notas de versão" da dependência antes de atualizar a dependência para uma nova versão.

Segundo, meu conselho:

Se o erro ocorrer no código fonte da equipe de desenvolvimento:

• Corrija-o de maneira profissional. (Se você corrigi-lo, você é o proprietário.)
• Quando estiver sob pressão do tempo, faça o melhor que puder - o que exige que você:
  • Veja o impacto potencial no usuário final: do bug em si e da correção proposta, para decidir se aceita a correção.
  • Estude trechos de código relacionados (usando as informações de histórico da sua ferramenta de gerenciamento de código-fonte) e discuta com seus colegas de trabalho (mas não ocupe muito tempo), até entender bem o problema e a solução.
• Sempre acompanhe o bug com um sistema de rastreamento de defeitos .

Se o erro ocorrer no código fonte de outra equipe:

• Empurre a equipe para corrigir o erro.
• Sempre arquive esse bug no sistema de rastreamento de defeitos da outra equipe .

Se o erro ocorrer no produto de outra empresa (ou nenhuma empresa):

• Nesse caso, correções em fita adesiva (ou soluções alternativas orientadas a dados ) podem ser a única maneira de corrigir o erro.
• Se for de código aberto, arquive esse bug em algum sistema de rastreamento de defeitos (possivelmente público) de qualquer maneira, para que alguém possa examiná-lo.

Depende muito da idade da base de código, eu acho. No código antigo, acho muito comum reescrever que a rotina COBOL de 20 anos não é divertida. Mesmo no código moderadamente novo que está em produção, ainda é bastante comum.

Eu diria que é muito comum.

Confira o post de Joel Spolsky: The Duct Tape Programmer

Posso dizer facilmente que quase todos os projetos que já participei tiveram que aplicar algum tipo de bandagem ou fita adesiva para cumprir os prazos e concluir uma tarefa. Não é bonito, não é limpo, mas faz o trabalho para que a empresa possa continuar funcionando e o projeto pode avançar de alguma forma.

Há uma diferença entre o mundo acadêmico e o mundo real, onde o software realmente precisa ser enviado sob restrições de tempo e negócios.

De certa forma, é colocá-lo debaixo do tapete, para adiar uma correção, até, esperançosamente, mais tarde. Infelizmente, com muita freqüência, a correção adiada nunca acontece e esse código encontra seu caminho para a produção.

É difícil dizer sem mais contexto - no seu exemplo, por que adicionar a instrução if não é a correção correta? É porque há algum outro bloco de código em algum lugar que deveria estar lidando com essa entrada?

A frequência com que as correções de bandagem são usadas depende de várias coisas, como a complexidade do código, se a pessoa mais familiarizada com o código está disponível (a pessoa responsável pela rotina COBOL de 20 anos de Craig pode ter deixado a empresa anos atrás. ) e os prazos envolvidos.

Com um prazo olhando para o seu rosto, você às vezes busca a solução mais segura, mesmo que seja apenas colocando um gesso em vez de corrigir a causa raiz. Tudo bem, desde que você não piore as coisas, mas é importante acompanhar o fato de que ainda não está correto e ainda precisa ser corrigido adequadamente.

Há casos em que esse tipo de correção é realmente bom e provavelmente o ideal (no que diz respeito à quantidade de tempo que leva para depurar).

Imagine um cenário em que você tenha 20 DLLs que deveriam funcionar como algum tipo de módulo para o seu executável principal, mas também exigem algumas informações do executável principal para serem executadas.

Se você quiser usar essas DLLs fora do executável principal, precisará falsificar alguns valores de retorno do executável principal porque. A.) Não existe neste contexto e B.) Você não deseja que exista neste contexto.

Dito isso, é melhor colocar algumas diretivas do compilador no seu código para garantir que você esteja executando um código completamente diferente ao falsificar os resultados e ao obter os resultados reais.

Em vez de colocar uma função ifinterna de outra pessoa, eu a {$ifdef}contornaria - dessa maneira ninguém a confunde com algo que deveria estar lá.