Você já encontrou um bug que não consegue resolver? O que você faz nesse caso?

Question

Você já encontrou um bug que não consegue resolver? O que você faz nesse caso?

#1 resposta do (5 votos)
#2 resposta do (1 votos)
#3 resposta do (1 votos)
#4 resposta do (1 votos)

5

Estamos desenvolvendo um CMS hospedado, algo como o WordPress.com. Quando criamos o módulo Galeria de Imagens , examinamos muitas bibliotecas jQuery, como easySlider , jCarousel e > Nivo Slider . Mas cada um deles tinha algum tipo de bug estranho nos navegadores. Nós quase colocamos 2 dias para descobrir de onde o bug era. Mas não conseguimos encontrar a fonte do problema. A razão mais importante pode ser que o nosso sistema seja agora complexo.

Aqui estão os problemas:

easySlider deslizante não foi transitório e foi abrupto.
O jCarousel estava deslizando as imagens com metade da largura no IE.
O Nivo Slider não ocultou a última imagem exibida, portanto, não era adequado para uma galeria de imagens com imagens heterogêneas.

Concluímos que precisamos encontrar uma biblioteca que funcione sem bug e procuramos e encontramos uma.

Mas minha pergunta é: é normal para grandes projetos que a fonte de um bug não possa ser encontrada e, em vez disso, ele está localizado com tentativa e erro e você simplesmente foge do bug? Você tem essa experiência?

debugging bug

por Saeed Neamati 04.09.2011 / 08:57

fonte

4 respostas

Tags debugging bug

Processamento Multi MVC vs. Processo Single MVC É legal colocar 'FSharp.Core.dll' do pacote redistribuível FSharp?

score 5 · Answer 1

We just concluded that we need to find a library which can work without bug, and we searched and found one.

Ou melhor, você pode entrar em contato com os respectivos autores dessas bibliotecas e enviar o bug que encontrou.

Você também pode se surpreender se esses autores responderem que o bug não existe. Por exemplo, eu usei jCarousel no passado e nunca tive nenhum problema de largura no IE. Seu caso pode ser um caso de borda muito estranho ou um bug introduzido na versão mais recente, mas também pode ser o fato de você estar usando a biblioteca errada.

Agora, se você entrar em contato com o autor e ele passar muito tempo corrigindo um bug enquanto houver prazos se aproximando, ou se a resposta dele não for útil, não há nada errado em abandonar uma biblioteca e escolher outra . Você também pode desativar um recurso com bugs na versão atual do seu site e procurar uma solução por conta própria , opcionalmente contribuindo para o biblioteca se for código aberto.

score 1 · Answer 2

Por definição, cada bug pode ser corrigido, talvez escrevendo seu próprio sistema operacional na linguagem assembler. Essa é uma das belezas da programação.

Em uma nota mais realista, o problema é encontrar uma correção para o bug que tenha um custo razoável. Reescrever uma parte do Linux é muito mais barato do que escrever seu próprio sistema operacional. Encontrar uma biblioteca que funciona é mais barato do que reescrever uma biblioteca quebrada.

O Drupal tem um truque pelo qual o HTML é dado ao html.tpl.php para ser escrito no navegador. Ao editar esse arquivo, eu tenho "corrigido" os bugs substituindo o HTML real pelo meu. Exemplos incluem a tradução do inglês para o chinês, a adição de um alternador de idioma em um canto não permitido da tela e a escolha de uma imagem aleatória para exibição. É de baixo nível, mas é possível.

Sempre é possível "corrigir" um bug substituindo o código que gera o problema. Quanto menor o pedaço que você substituir, menor será o custo.

score 1 · Answer 3

Eu diria que você fez a coisa certa, possivelmente levou muito tempo para chegar lá. Para coisas como bibliotecas de código aberto de terceiros, eu prefiro fazer um rápido "pico" naquelas que parecem mais promissoras. O "pico" é um teste de viabilidade rápido, com pequenos pedaços isolados de código, para determinar rapidamente se a biblioteca será adequada ao problema. Se não for, então você pode rapidamente passar para a alternativa.

É claro que, se nenhum deles for adequado, você terá de escrever sua própria implementação ou, para aquele que for o mais próximo, você pode corrigir o problema ou trabalhar com o autor, como a MainMa sugere. No caso de consertá-lo, você utilizaria técnicas de depuração padrão, mas o método de pico pode ajudar com isso, pois você tem menos código próprio atrapalhando e pode isolar melhor o código de terceiros que é problemático.

score 1 · Answer 4

Qualquer bug pode ser 'encontrado' no sentido de que você terminará em uma das seguintes situações:

Você pode identificar o arquivo e a linha exatos em seu código, onde as coisas dão errado. Se você está aqui, bom, você praticamente resolveu o bug.
Você conclui que os requisitos que não são cumpridos não são, na verdade, bem definidos: podem ser muito vagos, contraditórios ou ambíguos. A solução, então, é voltar para o cliente e obter os requisitos antes de lançar alterações aleatórias em seu código.
Você pode identificar uma seção do seu código onde as coisas dão errado, mas essa seção é tão complicada que analisar seu comportamento e compará-la ao comportamento desejado levaria muito tempo. Este é um sinal de alarme e você deve reescrever esse código imediatamente.
Você pode identificar o erro em algum lugar fora do seu próprio código: uma biblioteca; uma implementação do navegador de javascript, CSS, HTML ou o que você estiver usando; implementação de outro host de um protocolo de rede; Se você puder, substitua o código defeituoso por uma alternativa que funcione. Se você não conseguir (por exemplo, com um bug de javascript), encontre uma solução alternativa, mas integre-a ao seu código de uma maneira que torne fácil e simples a mudança para o comportamento compatível. Idealmente, você quer ser capaz de detectar um ambiente não compatível e ajustar automaticamente.

Então, embora você não consiga sempre encontrar o bug no sentido do primeiro ponto, você deve sempre ser capaz de acabar em uma dessas quatro situações, e todas elas têm soluções (embora algumas possam ser bastante dolorosas ).