Imagine que você está criando um player de vídeo em JavaScript. Este player de vídeo faz um loop do vídeo do usuário repetidamente usando uma função recursiva e, por isso, o navegador dispara um too much recursion RangeErrorem algum momento.

Provavelmente ninguém vai usar tanto o recurso de loop. Seu aplicativo nunca lançará esse erro, mesmo que o usuário tenha deixado o aplicativo em loop por uma semana, mas ele ainda exista. A solução do problema exigirá que você redesenhe a maneira como o loop funciona em seu aplicativo, o que levará um tempo considerável. O que você faz? Por quê?

• Corrigir o erro

• Deixe o bug

Você não deveria apenas consertar bugs nas quais as pessoas tropeçariam? Quando o conserto de bugs se torna um exagero, se é que alguma vez acontece?

EDITAR:

Se a abordagem recursiva de não causar um bug real for uma preocupação para você, suponha que, a cada vez que o player reproduza um vídeo, uma variável seja aumentada 1. Após 2 ⁵³ loops, essa variável será excedida e seu programa não poderá lidar com isso, lançando uma exceção.

Você tem que ser pragmático.

Se é improvável que o erro seja acionado no mundo real e o custo para correção seja alto, duvido que muitas pessoas considerem um bom uso de recursos para correção. Com base nisso, eu diria que o deixe, mas garanta que o hack seja documentado para você ou seu sucessor em alguns meses (consulte o último parágrafo).

Dito isso, você deve usar esse problema como uma "experiência de aprendizado" e na próxima vez que executar o loop não usar um loop recursivo desnecessariamente.

Além disso, esteja preparado para esse relatório de bug. Você ficaria surpreso com o quão bom os usuários finais são em ultrapassar os limites e descobrir defeitos. Se isso se tornar um problema para os usuários finais, você precisará corrigi-lo - então ficará feliz por ter documentado o hack.

Houve um erro semelhante no Windows 95 que causou computadores para crash após 49,7 dias . Foi observado apenas alguns anos após o lançamento, uma vez que pouquíssimos sistemas Win95 permaneceram ativos por muito tempo. Portanto, há um ponto: os erros podem se tornar irrelevantes por outros erros mais importantes.

O que você precisa fazer é uma avaliação de risco para o programa como um todo e uma avaliação de impacto para erros individuais.

• Este software está em um limite de segurança?
• Em caso afirmativo, esse bug pode resultar em uma exploração?
• Este software é "missão crítica" para os usuários pretendidos? (Veja a lista de itens para os quais o EULA do Java o impede de usá-lo )
• O bug pode resultar em perda de dados? Perda financeira? Perda de reputação?
• Qual a probabilidade desse bug ocorrer? (Você incluiu isso no seu cenário)

E assim por diante. Isso afeta a triagem de erros , o processo de decidir quais erros serão corrigidos. Praticamente todos os softwares de remessa possuem listas muito longas de pequenos bugs que ainda não foram considerados importantes o suficiente para serem corrigidos.

As outras respostas já são muito boas e sei que seu exemplo é apenas um exemplo, mas quero destacar uma grande parte desse processo que ainda não foi discutida:

Você precisa identificar suas suposições e depois testá-las em casos extremos.

Olhando para o seu exemplo, vejo algumas suposições:

• A abordagem recursiva acabará por causar um erro.
• Ninguém verá esse erro porque os vídeos demoram muito para serem alcançados para atingir o limite de empilhamento.

Outras pessoas discutiram a primeira suposição, mas olhe para a segunda suposição: e se o meu vídeo tiver apenas uma fração de segundo?

E claro, talvez esse não seja um caso de uso muito comum. Mas você está realmente certo de que ninguém vai fazer upload de um curto vídeo? Você está assumindo que os vídeos têm uma duração mínima e provavelmente nem percebeu que estava assumindo alguma coisa! Essa suposição poderia causar outros erros em outros lugares do seu aplicativo?

Pressupostos não identificados são uma enorme fonte de erros.

Como eu disse, sei que seu exemplo é apenas um exemplo, mas esse processo de identificação de suas suposições (que geralmente é mais difícil do que parece) e, em seguida, pensar em exceções a essas suposições é um grande fator para decidir onde gastar seu tempo.

Portanto, se você estiver pensando "Eu não deveria ter que programar isso, pois isso nunca acontecerá", você deve dedicar algum tempo para realmente examinar essa suposição. Você sempre pensa em casos de canto que podem ser mais comuns do que você pensava originalmente.

Dito isto, há um ponto em que isso se torna um exercício de futilidade. Você provavelmente não se importa se o seu aplicativo JavaScript funciona perfeitamente em uma calculadora TI-89, portanto, gastar qualquer quantidade de tempo com isso é desperdiçado.

As outras respostas já abordaram isso, mas chegar a essa linha entre "isso é importante" e "isso é uma perda de tempo" não é uma ciência exata e depende de muitos fatores que podem ser completamente diferentes de um pessoa ou empresa para outra.

Mas grande parte desse processo é primeiro identificar suas suposições e depois tentar reconhecer exceções a essas suposições.

Eu recomendo que você leia o seguinte artigo:

Confiabilidade e suas ameaças: uma taxonomia

Entre outras coisas, descreve vários tipos de falhas que podem ocorrer no seu programa. O que você descreveu é chamado de falha inativa e, neste documento, é descrito assim:

Uma falha está ativa quando produz um erro, caso contrário, está inativa. Uma falha ativa é a) uma falha interna anteriormente inativa e que foi ativada pelo processo de computação ou pelas condições ambientais ou b) uma falha externa. A ativação de falha é a aplicação de uma entrada (o padrão de ativação) a um componente que faz com que uma falha inativa se torne ativa. A maioria das falhas internas alterna entre seus estados inativos e ativos

Tendo descrito isso, tudo se resume a uma relação custo-benefício. O custo consistiria em três parâmetros:

• Com que frequência o problema se apresentaria?
• Quais seriam as consequências?
• Quanto isso incomoda você pessoalmente?

Os dois primeiros são cruciais. Se algum bug se manifestar uma vez na lua azul e / ou ninguém se importar com isso, ou tiver uma solução alternativa perfeitamente boa e prática, você poderá documentá-lo com segurança como um problema conhecido e passar para outros mais desafiadores e mais tarefas importantes. No entanto, se o bug causar uma transação monetária falhar ou interromper um longo processo de registro, frustrando o usuário final, você deverá agir de acordo com ele. O terceiro parâmetro é algo contra o qual não aconselho veementemente. Nas palavras de Vito Corleone:

Não é pessoal. São negócios.

Se você é um profissional, deixe as emoções de lado e aja de maneira ideal. No entanto, se o aplicativo que você está escrevendo é um hobby seu, você está emocionalmente envolvido, e o terceiro parâmetro é tão válido quanto qualquer outro em termos de decisão de corrigir ou não um bug.

Esse bug só permanece desconhecido até o dia em que alguém coloca seu player em uma tela de lobby executando uma apresentação da empresa 24 horas por dia, 7 dias por semana. Então ainda é um bug.

A resposta para o que você faz? é realmente uma decisão de negócios, não de engenharia:

• Se o bug afeta apenas 1% dos usuários e o player não suporta um recurso exigido por outros 20%, a escolha é óbvia. Documente o bug e continue.
• Se a correção estiver na sua lista de tarefas, geralmente é melhor corrigi-la antes de começar a adicionar novos recursos. Você obterá os benefícios do processo de desenvolvimento de software com defeito zero e não perderá muito tempo, já que ele está na sua lista.

Especialmente nas grandes empresas (ou grandes projetos), existe uma maneira muito pragmática de estabelecer o que fazer.

Se o custo da correção for maior que o retorno que a correção trará, mantenha o bug. Viceversa, se a correção retornar mais do que seu custo, corrija o erro.

No cenário de exemplo, depende de quanto os usuários esperam perder versus a quantidade de usuários que ganhará se desenvolver novos recursos em vez de corrigir esse bug caro.

tl; dr É por isso que RESOLVED/WONTFIXé uma coisa. Só não use demais - a dívida técnica pode se acumular se você não tomar cuidado. Esse é um problema fundamental em seu design, que provavelmente causará outros problemas no futuro? Então conserte. De outra forma? Deixe-o até que se torne uma prioridade (se for o caso).

Na verdade, existem três erros na situação que você descreve:

1. A falta de um processo para avaliar todos os erros registrados (você registrou o erro em seu ticket / lista de pendências / qualquer sistema existente, certo?) Para determinar se deve ser corrigido ou não. Esta é uma decisão de gerenciamento.

2. A falta de habilidades em sua equipe que leva ao uso de soluções defeituosas como essa. É urgente que isso seja resolvido para evitar problemas futuros. (Comece a aprender com seus erros.)

3. O problema que o vídeo pode parar de exibir após um longo período de tempo.

Apenas dos três erros (3) pode não precisar ser corrigido.

Há muitas respostas aqui discutindo a avaliação do custo do bug corrigido, em vez de deixá-lo. Todos eles contêm bons conselhos, mas eu gostaria de acrescentar que o custo de um bug geralmente é subestimado, possivelmente muito subestimado. A razão é que os bugs existentes atrapalham as águas para desenvolvimento e manutenção contínuos. Fazer com que seus testadores controlem vários bugs "não corrigem" enquanto navegam no seu software tentando encontrar novos bugs, tornando seu trabalho mais lento e mais propenso a erros. Alguns bugs "não corrigem" que provavelmente não afetarão os usuários finais ainda tornarão o desenvolvimento contínuo mais lento e o resultado será mais complicado.

Uma coisa que aprendi nos meus anos de codificação é que um bug voltará. O usuário final sempre o descobrirá e apresentará um relatório. A correção ou não do bug é "meramente" uma questão de prioridade e prazo.

Tivemos grandes bugs (na minha opinião, major) que foram decididos contra a correção em um lançamento, apenas para nos tornar um impeditivo para o próximo lançamento, porque o usuário final tropeçou nele várias vezes. O mesmo vice-versa - fomos pressionados a corrigir um bug em um recurso que ninguém usa, mas era útil para a gerência ver.

Há três coisas aqui:

Princípios

Este é um lado da moeda. Até certo ponto, eu sinto que é bom para insistir na correção de bugs (ou maus implementações, mesmo que "trabalhar"), mesmo que ninguém está percebendo isso.

Veja da seguinte maneira: o problema real não é necessariamente o bug, no seu exemplo, mas o fato de um programador pensar que era uma boa idéia implementar o loop dessa maneira, em primeiro lugar. Era óbvio desde o primeiro momento que essa não era uma boa solução. Agora existem duas possibilidades:

• O programador simplesmente não percebeu. Bem ... um programador deve desenvolver uma intuição de como seu código é executado. Não é como recursão é um conceito muito difícil. Ao consertar o bug (e suar com todo o trabalho adicional), ele talvez aprenda algo e se lembre dele, apenas para evitar o trabalho adicional no futuro. Se o motivo foi que ele simplesmente não teve tempo suficiente, a gestão pode aprender que os programadores não precisam de mais tempo para criar código de maior qualidade.

• O programador percebeu, mas considerou "não um problema". Se isso for deixado em pé, será desenvolvida uma cultura de laissez-faire que, em última análise, levará a erros onde realmente dói. Nesse caso em particular, quem se importa. Mas e se esse programador estiver desenvolvendo um aplicativo bancário na próxima vez e decidir que uma certa constelação nunca acontecerá. Então faz. Tempos ruins.

Pragmatismo

Este é o outro lado. De curso você provavelmente iria, neste caso particular, não corrigir o erro. Mas cuidado - existe pragmatismo e depois existe pragmatismo. Um bom pragmatismo é se você encontrar uma solução rápida, mas sólida e bem fundamentada para um problema. Ou seja, você evita o excesso de design de coisas, mas as coisas que você realmente implementa ainda são bem pensadas. O mau pragmatismo é quando você apenas invalida algo que funciona "exatamente" e que quebra na primeira oportunidade.

Falhe rápido, falhe duro

Em caso de dúvida, falhe rápido e com dificuldade.

Isso significa, entre outros, que seu código percebe a condição de erro, não o ambiente.

Neste exemplo, o mínimo que você pode fazer é fazê-lo para que o erro de tempo de execução difícil ("profundidade da pilha excedida" ou algo parecido)) não ocorra, substituindo-o por uma exceção rígida. Você pode, por exemplo, ter um contador global e decidir arbitrariamente que salve após 1000 vídeos (ou qualquer número alto o suficiente para nunca ocorrer em uso normal e baixo o suficiente para continuar funcionando na maioria dos navegadores). Em seguida, dê a essa exceção (que pode ser uma exceção genérica, por exemplo, uma RuntimeExceptionem Java ou uma sequência simples em JavaScript ou Ruby) uma mensagem significativa. Você não precisa se esforçar ao máximo para criar um novo tipo de exceção ou o que fizer em sua linguagem de programação específica.

Dessa forma, você tem

• ... documentou o problema dentro do código.
• ... tornou um problema determinístico. Você sabe que sua exceção acontecerá. Você não está à mercê das mudanças na tecnologia subjacente do navegador (pense não apenas no navegador de PC, mas também em smartphones, tablets ou tecnologia futura).
• ... tornou mais fácil corrigi-lo quando você eventualmente precisar corrigi-lo. A fonte do problema é apontada pela sua mensagem, você receberá uma resposta significativa e tudo mais.
• ... ainda não perdeu tempo processando erros "reais" (lembre-se, você nunca espera que o erro ocorra).

Minha convenção é prefixar essas mensagens de erro com a palavra "Paranoia:". Este é um sinal claro para mim e para todo mundo que eu nunca espero que esse erro aconteça. Eu posso separá-los claramente das exceções "reais". Se eu vejo alguém assim em uma GUI ou em um arquivo de log, sei com certeza que tenho um problema sério - eu nunca esperava que eles ocorressem, afinal. No presente momento eu entrar em modo de crise (com uma boa chance de resolvê-lo de forma rápida e com bastante facilidade, como eu sei exatamente onde o problema ocorreu, poupando-me de um monte de depuração espúria).

Um post-it na mesa de um desenvolvedor sênior no meu local de trabalho diz

Isso ajuda alguém?

Eu acho que esse é frequentemente um bom ponto de partida para o processo de pensamento. Sempre há muitas coisas para corrigir e melhorar - mas quanto valor você realmente está adicionando? ... seja em usabilidade, confiabilidade, capacidade de manutenção, legibilidade, desempenho ... ou qualquer outro aspecto.

Três coisas vêm à mente:

Primeiro , o impacto de um bug identificado precisa ser minuciosamente investigado antes que a decisão de deixar o bug no código possa ser tomada de maneira responsável. (No seu exemplo, pensei imediatamente sobre o vazamento de memória que a pilha crescente representa e que pode tornar seu navegador cada vez mais lento a cada recursão.) Essa investigação completa geralmente leva mais tempo do que a correção do bug, portanto, prefiro corrigir o bug na maioria dos casos.

Segundo , os bugs tendem a ter mais impacto do que se pensa a princípio. Estamos todos familiarizados com o código de trabalho, porque este é o caso "normal". Erros, por outro lado, são uma "exceção". Obviamente, todos nós vimos muitos bugs, mas vimos muito mais código funcionando em geral. Portanto, temos mais experiência em como o código de trabalho se comporta do que em como o código de buggy se comporta. Existem bilhões de livros sobre o código de funcionamento e o que ele fará em quais situações. Não há quase nada sobre o comportamento do código de buggy.

A razão para isso é simples: os bugs não são ordem, mas caos . Eles geralmente têm um rastro de ordem neles (ou o contrário: eles não destroem completamente a ordem), mas sua natureza de buggy é uma destruição da ordem que o programador queria. O próprio caos tende a desafiar a estimativa correta. É muito mais difícil dizer o que um programa com um bug fará do que um programa correto, apenas porque não se encaixa mais em nossos padrões mentais.

Terceiro , seu exemplo continha o aspecto de que a correção do bug significaria ter que redesenhar o programa. (Se você retirar esse aspecto, a resposta é simples: corrija o erro, não demorará muito, pois não é necessário reprojetar. Caso contrário, :) Nesse caso, eu perderia a confiança no programa da maneira como ele é projetado atualmente. O redesenho seria uma maneira de restaurar essa confiança.

Tudo isso dito , os programas são coisas que as pessoas usam, e um recurso ausente ou um segundo bug realmente pesado em outro lugar pode ter prioridade sobre a correção do bug. É claro que, então, siga o caminho pragmático e faça outras coisas primeiro. Mas nunca esqueça que uma primeira estimativa rápida do impacto de um bug pode estar totalmente errada.

Probabilidade baixa / Consequências leves = Correção baixa

• Se a probabilidade de ocorrência é muito baixa
• Se as consequências da ocorrência são leves
• Então o bug não representa uma ameaça, então não é uma correção prioritária.

Mas isso não pode se tornar uma muleta para desenvolvedores preguiçosos ...

• O que significa "ocorrência muito baixa"?
• O que "consequências leves" significam?

Para declarar que a probabilidade de ocorrência é muito baixa e as consequências são leves, a equipe de desenvolvimento deve entender o código, os padrões de uso e a segurança.

A maioria dos desenvolvedores se surpreende ao saber que coisas que eles originalmente pensavam nunca aconteceriam, na verdade acontecem muito

Nosso sistema educacional não ensina muito bem a probabilidade e a lógica. A maioria das pessoas, incluindo a maioria dos engenheiros de software, tem uma lógica e uma intuição de proabilidade. Experiência com problemas do mundo real e experiência com simulações extensivas são a única maneira que conheço para corrigir isso.

Confronte sua intuição com dados do mundo real

É importante fazer vários logs para poder seguir os padrões de uso. Preencha o código com afirmações de coisas que você acha que não deveriam acontecer. Você ficará surpreso com o que eles fazem. Dessa forma, você poderá confrontar sua intuição com dados concretos e refiná-los.

Meu exemplo de um problema leve e uma medida de controle

Em um site de comércio eletrônico em que trabalhei há muito tempo, outro programador cometeu um erro: em alguma condição obscura, o sistema debitava o cliente um centavo a menos do que o registrado nos logs. Descobri o bug porque fiz relatórios para identificar as diferenças entre os logs e os saldos da conta para tornar o sistema de contabilidade mais resiliente. Eu nunca corrigi esse bug porque a diferença era muito pequena. A diferença foi calculada diariamente e foi inferior a US $ 2,00 mensais. Aconteceu que estávamos desenvolvendo um sistema totalmente novo que em um ano deveria substituir o atual. Não faz sentido desviar recursos de projetos potencialmente lucrativos para consertar algo que custa US $ 2,00 mensais e foi submetido a uma medida de controle apropriada.

Conclusão

Sim, existem erros que não precisam ser corrigidos imediatamente, que não são importantes o suficiente para atrasar o desenvolvimento de novos recursos. No entanto, o sistema deve ter controle da ocorrência desse bug para garantir que ele seja pequeno, porque não podemos confiar em nossa própria intuição.

Eu acho que isso está fazendo a pergunta errada desde o início.

A questão não é "devo corrigir este erro ou não devo corrigir esse erro". Qualquer desenvolvedor tem um tempo limitado. Portanto, a pergunta é "qual é a coisa mais útil que posso fazer em uma hora ou quatro horas ou uma semana".

Se a correção desse bug é a coisa mais útil a ser feita, porque melhora o software na maior quantidade para a maioria das pessoas, corrija o bug. Se você puder fazer melhorias maiores em outro lugar, adicionando recursos que faltam às pessoas ou corrigindo um bug mais importante, faça essas outras coisas. E pontos de bônus extras para qualquer coisa que torne seu desenvolvimento futuro mais eficiente.

A correção de bugs é sempre um exagero

Vamos classificar a parte do bug primeiro.

É um erro honesto , por exemplo, um erro pontual ou uma sombra variável que escapou aos testes? Nesse caso, espero que, além de "consertar" o problema, você também tenha escrito novos testes de unidade, aproveitando a oportunidade para refatorar o código próximo, onde todos esses trabalhos são úteis .

Se, no entanto, é realmente uma falha de design , no seu caso, você deve reavaliar o design ou, na pior das hipóteses, desativar esse recurso.

Então, por favor, não tente consertar .

Você poderia fazer o pior, é claro - você poderia tentar a metodologia hack-upon-hack . O loop de vídeo é um hack (arquitetura incorreta e há falhas conhecidas). Você pode adicionar um limite de loop , para que, após N iterações (testadas abaixo do limite do navegador), o loop termine.

As ramificações são óbvias, agora você precisa suportar o código quebrado e o novo limite de loop.

PS pede desculpas pela visão extrema.

PPS Uma observação sobre terminologia: você não pode "consertar" um bug. Bem, talvez um veterinário poderia, mas não vamos lá ;-). Os problemas são resolvidos ou "corrigidos", enquanto os erros são removidos ou contornados.