Quando é que o conserto de erros se torna um exagero?

128

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 53 loops, essa variável será excedida e seu programa não poderá lidar com isso, lançando uma exceção.

Tiago Marinho
fonte
95
Não mexa com meu exemplo cenário mate
Tiago Marinho
15
@PlasmaHH Estou usando esse cenário hipotético para explicar minha pergunta. Se o bug existe ou não não importa em tudo
Tiago Marinho
13
@TiagoMarinho: o ponto que estou tentando destacar é: às vezes, é a coisa certa a fazer para definir um cenário como o comportamento pretendido.
PlasmaHH
23
Por que diabos você executaria esse ciclo usando recursão em primeiro lugar? Você não pode querer corrigir o erro, mas com certeza você deveria reconsiderar o seu processo de design :-)
jamesqf
28
Isso parece mais uma questão de negócios. Você precisa priorizar com base no custo a corrigir e no impacto / frequência do bug.
Casey Kuball

Respostas:

164

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.

mcottle
fonte
119
Concordo totalmente com "Você ficaria surpreso com o quão bom os usuários finais são em ultrapassar os limites e descobrir defeitos".
manchado
74
Os usuários finais não são de forma alguma restritos pelo que você considera um uso razoável do seu software. Haverá usuários que desejam repetir um vídeo para sempre. É um recurso que seu software fornece, para que ele o utilize.
gnasher729
36
@ gnasher729 Os vídeos "10 horas XXXX" no Youtube são um bom identificador que, de fato, algumas pessoas querem apenas repetir algo para sempre.
22816 Chris Cirefice
23
Outro problema: se o seu software é popular, alguém encontra um bug que realmente acontece apenas em uma situação rara, o publica na Internet e, de repente, todos e seus cães dizem "esse software é um lixo, ele trava se eu exibir um vídeo para um dia". Ou um concorrente usa-o para demonstrar como é fácil travar seu aplicativo.
gnasher729
4
Ênfase no último parágrafo. Você sabia que o MacOS Classic travaria se recebesse 32.768 eventos consecutivos de "pressionar o mouse" sem um evento intermediário de "liberação do mouse"?
Mark
79

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.

pjc50
fonte
2
Também me lembro do bug (hardware) em algumas CPUs Intel em que um valor de ponto flutuante específico deu errado.
5
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug é o que eu acredito que você está se referindo. Ficou acordado um ano antes que alguém percebesse.
Jeutnarg 17/10
10
@ gnasher729 - Na verdade, eles já estavam no fundo e ainda estavam cavando :) A maioria das pessoas teve que reinstalar o Win 95 com mais frequência do que 49,7 dias no IIRC.
Mcottle
4
@Luaan O comentário foi planejado como uma escavação leve em M $, daí o sorriso após a primeira frase. Eles estavam atrás da bola de oito em 95 porque saiu muito tarde em 95 (provavelmente porque o lançamento do Win95 em 1996 teria sido um aspecto ruim), meio cozido (Lembra do USB BSOD?) E inclinado a se tornar instável e exigir reinstalações regulares daí a minha segunda frase - que nunca mencionou a execução de um servidor no Windows 95, não sei de onde você tirou isso (flashbacks?). O CD do segundo lançamento melhorou o assunto, mas o lançamento inicial de 95 foi doozy.
Mcottle
5
TBH Acho que foi o fiasco do "Windows para navios de guerra" que causou mais danos à reputação ( archive.wired.com/science/discoveries/news/1998/07/13987 ) e que estava usando o NT. As máquinas Unix da época podiam gerenciar uptime de vários anos, mesmo usando versões (muito antigas) do Linux. Todos os computadores domésticos também eram capazes de alto tempo de atividade, embora raramente usados ​​dessa maneira. Vi micros da BBC incorporados em exposições educacionais uma década depois de obsoletas.
Pjc50
33

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.

Kevin Workman
fonte
Muito bom ponto Kevin. Nota meu comentário sobre a resposta selecionada acima que incide sobre a questão de análiseWhat's the worst thing that could happen?
OMY
Outra suposição aqui é que uma pilha sempre crescente só levará a problemas quando atingir um tamanho de estouro. De fato, a pilha pode ser um recurso normal, pois esse bug está constantemente vazando. Todo o navegador pode se tornar cada vez mais lento em pequenos bits em cada iteração hrecursão ^ H ^ H ^ H ^ H ^ H ^.
Alfe
1. O OP nunca disse que o problema foi causado por uma pilha crescente. Pode ser facilmente causado por um erro em uma rotina de contador (dec -> div / 0?). 2. Se o problema for um estouro de pilha, essa pergunta não deve ser publicada no StackOverflow? <rimshot!> ;-D
OMY
@OMY Para quem esse comentário é direcionado?
Kevin Workman
13

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.

Vladimir Stokic
fonte
Não é pessoal. É negócio ”é de Michael, eu acho, não de Vito. (Você ficaria surpreso quão bom os usuários finais estão a empurrar contra os limites e descobrir defeitos)
384X21
Na verdade, é de Vito, se você ler o livro. Mesmo no filme, é Tom Hagen que diz isso primeiro quando discute com Sonny sobre se eles devem ir para os colchões, e somente depois disso Michael diz pela primeira vez a famosa citação: "Não é pessoal, Sonny. São estritamente comerciais." . " Mas Hagen aprendeu isso com Vito.
Vladimir Stokic
11

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.
Dmitry Grigoryev
fonte
5

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.

JoulinRouge
fonte
6
O ROI para corrigir um erro raramente é fácil de avaliar - você geralmente precisa confiar em seu julgamento.
Ant
O retorno que a correção trará é principalmente uma reputação quase impossível de quantificar. Se eu sou o único que sabe que pode haver um erro e, em um ou dois anos, troco de emprego e a nova empresa pensa em incorporar um player de vídeo em seu produto (possivelmente vendendo milhões de unidades), eu recomendaria o uso este?
Jerry Jeremiah
@JerryJeremiah, se o erro impedir a execução de um processo comercial, não se trata de reputação, depende da importância do processo comercial. E em todos os casos e em todas as políticas que você aplica para corrigir bugs ou não, é necessário fazer uma avaliação subjetiva com base em sua experiência e conhecimento. Mesmo se você puder saber o número exato de usuários que enfrentarão o bug, você ainda precisará fazer uma escolha humana (também a política de ROI também pode incluir estatísticas de acertos de bugs para extender custos). Como hoje não existe uma maneira mecânica de saber a priori a coisa perfeita a fazer.
JoulinRouge
5

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).

Raças de leveza em órbita
fonte
5

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.

Bent
fonte
Obrigado por apontar os problemas de 2ª ordem. Muitas pessoas tratam apenas o sintoma, e a causa continua criando mais sintomas.
Jaxter
4

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.

Buhb
fonte
2

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.

Aleksandra
fonte
2

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).

AnoE
fonte
2
Sinto muito se você se sente assim com relação a quanto tempo eu aceitei uma resposta. Em minha defesa, eu simplesmente não sabia que a pergunta teria> 10.000 pontos de vista e muitas respostas no momento da aceitação. De qualquer forma, ainda não mudei de idéia sobre a melhor resposta.
Tiago Marinho
@TiagoMarinho, não há problema, o comentário não foi direcionado principalmente para você pessoalmente, e eu não esperava que você reconsiderasse. ;) Estou mais perplexo com as motivações de quem votou para realmente excluir minha resposta ... Além disso, há muitas votações negativas para várias respostas aqui sem nenhum comentário. Não tenho certeza se é assim que é feito nesta área específica do SE.
AnoE
Eu concordo completamente com a votação estranha
Tiago Marinho
Gostaria de saber se, pelo menos neste caso, o tratamento é melhor que a cura. Se você estiver decidindo se deve executar um tratamento especial para uma falha de design que você já identificou, faz sentido comparar o custo total do ciclo de vida de a) implementar o tratamento de erros e potencialmente agir sobre o erro quando ocorrer, corrigindo o design, ou b) apenas corrigindo o design em primeiro lugar.
Jaxter
@jaxter, exatamente. Daí minha abordagem de abrir a mente para uma correção de bug (mesmo que pareça um exagero), mas quando você decide não consertar o bug, pelo menos implemente a coisa rápida. Obviamente, se a solução à prova de falhas for mais cara que a correção "real" em primeiro lugar, evite-a e faça a correção real.
AnoE 21/10
1

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.

topo morto
fonte
0

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.

Alfe
fonte
2
Por favor, deixe um comentário quando você votar. Devemos saber qual é a crítica para melhorar a resposta.
Alfe
0

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.

Lucas
fonte
-1

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.

gnasher729
fonte
Não tenho certeza se a métrica utilitária funciona melhor aqui. Claramente, o exemplo do player de vídeo foi projetado para ter baixo impacto, mas mesmo isso não é infalível. Um respondente já citou o loop promocional 24 horas por dia, 7 dias por semana, em um caso de uso de lobby, e outro pode ser um quiosque em uma convenção de vendas / tecnologia que dura uma semana. Ambos custariam rep e / ou dinheiro para os negócios, de forma não trivial.
Jaxter
Isso significaria que a correção do bug oferece mais benefícios do que o inicialmente esperado, por isso deve aumentar mais as prioridades. Assim, você terá mais sucesso na vida se sua opinião sobre o que é mais útil estiver de acordo com a realidade, tanto quanto possível.
precisa saber é o seguinte
-2

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.

Dima Tisnek
fonte
Você realmente quis dizer que é sempre "exagero"? Eu acho que você pode ter misturado definições em algum lugar. Excesso de capacidade significa "trabalhar além do necessário" ou, em outras palavras, é mais do que qualquer um deveria fazer. Você está afirmando que a correção de bugs está sempre exagerada, ao mesmo tempo em que implora às pessoas que não basta trabalhar e que devemos fazer mais trabalho além disso, o que não faz sentido.
Doppelgreener
@doppelgreener Vejo como isso pode ser confuso. a correção de bugs é uma prática terrível e nunca deve ser feita. Por outro lado, adaptar o design ou a arquitetura de software aos requisitos variáveis ​​é uma boa prática a ser seguida. O mesmo vale para a correção de erros honestos, supondo que seja feito da maneira correta.
Dima Tisnek
2
Não sei de que tipo de correção de bug você está falando, mas no meu dia-a-dia "mudar a arquitetura" é um método de correção de bug. Você pode definir o que está coletando sob o termo "correção de bugs".
Doppelgreener 20/10
@doppelgreener - O termo "correção" recebe um significado especial em algumas formas de Gerenciamento de Qualidade e esse uso especializado foi adotado por muitos gerentes de programação. Uma " correção " é apenas uma solução temporária ou solução alternativa, enquanto uma verdadeira " solução " para o problema requer identificação e eliminação da " causa raiz ". No software, um bug pode ser tão simples quanto uma vírgula extraviada, onde a correção (correção da vírgula) É a solução, mas se o bug for causado por algo maior, a correção (ex: limitadores de loop) não será a mesma que a solução (redesenhar / reescrever).
OMY
2
@OMY Obrigado pela explicação. Eu sinto que, como essa definição de "correção" não está sendo usada pela pergunta, a resposta deve responder ao sentido da palavra que está sendo usada.
Doppelgreener