É razoável insistir em reproduzir todos os defeitos antes de diagnosticar e consertar o defeito?

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Você deve dar o melhor de si. Eu sei que às vezes há condições e ambientes que são tão complexos que não podem ser reproduzidos exatamente , mas você certamente deve tentar se puder.

Se você nunca reproduziu o bug e o viu por si mesmo, como você pode ter 100% de certeza de que realmente o corrigiu? Talvez sua correção proposta introduza algum outro bug sutil que não se manifestará, a menos que você teste reproduza o defeito original.

If I am a senior developer, should I be able to read (multithreaded) code and create a mental picture of what it does in all use case scenarios rather than require to run the application, test different use case scenarios hands on, and step through the code line by line? Or am I a poor developer for demanding that kind of work environment? Is debugging for sissies?

Eu não confiaria em alguém que executa o código "em sua cabeça", se essa é a abordagem somente . É um bom lugar para começar . Reproduzindo o bug e corrigindo-o e, em seguida, demonstrando que a solução impede que o bug ocorra novamente - é aí que ele deve terminar .

How should I talk with my team to convince them that my approach is reasonable, conservative and more bulletproof?

Porque se eles nunca reproduziram o bug, eles não podem saber ao certo se ele foi corrigido. E se o cliente voltar e reclamar que o bug ainda está lá, não é uma coisa boa. Afinal, eles estão pagando a você muito $$$ (suponho) para lidar com esse problema.

Se você falhar para corrigir o problema corretamente, você quebrou a fé do cliente (até certo ponto) e se houver concorrentes em seu mercado, eles podem não ser seus clientes.

Como eles pretendem verificar se o bug em questão foi corrigido? Eles querem enviar o código não testado para o usuário e deixá-lo descobrir? Qualquer configuração de teste que nunca foi mostrada para reproduzir o erro não pode ser usada para mostrar a ausência do erro. Você certamente não precisa reproduzir todo o ambiente do cliente, mas precisa do suficiente para reproduzir o erro.

Não acho que seja irracional tentar reproduzir todos os erros antes de corrigi-los. No entanto, se você tentar reproduzi-lo e não conseguir, será mais uma decisão de negócios se os patches cegos são ou não uma boa ideia.

O ideal é que você queira reproduzir cada bug para que, no mínimo, possa testar se foi corrigido.

Mas ... Isso pode nem sempre ser viável ou fisicamente possível. Especialmente com software do tipo 'empresa', onde cada instalação é única. Há também a avaliação de custo / benefício. Um par de horas examinando o código e fazendo algumas suposições sobre um problema não crítico pode custar muito menos do que ter uma equipe de suporte técnico passando semanas tentando configurar e duplicar o ambiente de um cliente exatamente na esperança de ser capaz de duplicar o problema. problema. Quando eu trabalhava no mundo da 'Enterprise', nós muitas vezes simplesmente mostrávamos aos programadores e faziam eles corrigirem erros no site, porque não havia como duplicar a configuração do cliente.

Então, duplique quando puder, mas se não puder, aproveite seu conhecimento do sistema e tente identificar o culpado no código.

Eu não acho que você deveria fazer uma reprodução do erro, um requisito para examinar o bug. Existem, como você mencionou, várias maneiras de depurar o problema - e você deve usar todas elas. Você deve se considerar sortudo por eles terem lhe dado um arquivo de log! Se você ou alguém da sua empresa conseguir reproduzir o bug, ótimo! Se não, você ainda deve tentar analisar os logs e encontrar as circunstâncias sob as quais o erro ocorreu. Pode ser possível, como seus colegas sugeriram, ler o código, descobrir quais condições o bug poderia acontecer e tentar recriar o cenário sozinho.

No entanto, não libere a correção real sem teste. Qualquer alteração que você fizer deverá passar pela rotina de desenvolvimento de desenvolvimento de teste padrão, controle de qualidade e integração. Pode ser difícil testar - você mencionou o código multithreaded, que é notoriamente difícil de depurar. É aqui que eu concordo com sua abordagem para criar uma configuração ou ambiente de teste. Se você encontrou um problema no código, deve achar muito mais simples criar o ambiente, reproduzir o problema e testar a correção.

Para mim, isso é menos um problema de depuração e mais um problema de atendimento ao cliente. Você recebeu um relatório de bug de um cliente; você tem a responsabilidade de fazer a devida diligência para encontrar o problema e corrigi-lo.

Na minha opinião ... como tomador de decisões, você deve ser capaz de justificar sua posição. Se o objetivo do departamento de suporte da 3ª linha é corrigir os erros no menor espaço de tempo com o esforço aceitável do cliente, então qualquer abordagem deve cumprir essa meta. Além disso, se for possível provar que a abordagem oferece os resultados esperados mais rápidos, não deve haver problema em convencer a equipe.

Tendo trabalhado em suporte, sempre esperei razoavelmente que o cliente pudesse fornecer algum "script" de ações que realizou para reproduzir consistentemente o erro e, se não consistentemente, os exemplos de candidatos que produziram o erro.

Se eu fosse novo no sistema e não tivesse experiência com o código, meus primeiros passos seriam tentar identificar as possíveis origens do erro. Pode ser que o log seja insuficiente para identificar um código candidato. Dependendo do cliente, eu posso estar inclinado a dar a eles uma versão de depuração para que eles possam lhe dar de volta arquivos de log que fornecem mais pistas sobre a posição do código ofensivo.

Se eu puder identificar rapidamente o bloco de código, o mapeamento visual do fluxo poderá ser suficiente para identificar o código. Caso contrário, a simulação baseada em testes unitários pode ser suficiente. Pode ser que a configuração de um ambiente de replicação do cliente leve menos tempo, especialmente se houver uma grande replicabilidade do problema.

Acho que você pode achar que sua abordagem deve ser uma combinação das soluções propostas e que saber quando sair de uma e passar para a próxima é a chave para fazer o trabalho com eficiência.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Eu digo sim, com algumas ressalvas.

• Acho que não há problema em ler o código e tentar encontrar lugares que pareçam problemáticos. Crie um patch e envie para o cliente para ver se isso resolve o problema. Se essa abordagem continuar a falhar, talvez seja necessário investigar outras opções. Lembre-se de que, embora você possa estar lidando com um bug , talvez ele não seja o bug que foi relatado.
• Se você não puder reproduzi-lo com razão e não encontrar sinalizadores vermelhos no código, talvez seja necessária uma coordenação mais próxima com o cliente. Eu voei para sites de clientes antes de fazer depuração no site. Não é o melhor ambiente de desenvolvimento, mas às vezes, se o problema for ambiental, encontrar a causa exata será mais fácil quando você puder reproduzi-lo de forma consistente.

Eu estive no lado do cliente da tabela neste cenário. Eu estava trabalhando em um escritório do governo dos EUA que usava um cluster de banco de dados Oracle incrivelmente grande (vários terabytes de dados e processava milhões de registros por dia).

Nós nos deparamos com um problema estranho que foi muito fácil para nós reproduzirmos. Nós relatamos o bug para a Oracle, e fomos e voltamos com eles por semanas, enviando logs para eles. Eles disseram que não foram capazes de reproduzir o problema, mas nos enviaram algumas correções que o esperado poderia resolver o problema. Nenhum deles fez.

Eles finalmente levaram alguns desenvolvedores até nosso local para depurar o problema no site. E foi aí que a causa raiz do bug foi encontrada e um patch posterior corrigiu corretamente o problema.

Se você não está certo sobre o problema, não pode ter certeza sobre a solução. Saber como reproduzir o problema de forma confiável em pelo menos uma situação de caso de teste permite provar que você sabe como causar o erro e, portanto, também permite provar, por outro lado, que o problema foi resolvido, devido à falta subsequente de erro no mesmo caso de teste após aplicar a correção.

Na maioria das vezes, o que originalmente parece um bug aleatório acaba tendo uma causa determinística que resulta em um bug deterministicamente reprodutível quando você sabe como. Os que desafiam isso, os verdadeiros Heisenbugs (bugs aparentemente aleatórios que desaparecem ao tentar testá-los em um ambiente estéril e monitorado), são 99,9% relacionados ao tempo, e uma vez que você entende isso, seu caminho para frente se torna mais claro; procure por coisas que poderiam falhar se alguma outra coisa fosse obter uma palavra no edgewise durante a execução do código, e quando você encontrar tal vulnerabilidade, tente explorá-la em um teste para ver se ela exibe o comportamento que você está tentando reproduzir.

Uma quantidade significativa de inspeção detalhada de código é normalmente exigida nessas situações; você tem que olhar para o código, abandonar quaisquer noções preconcebidas de como o código é suposto se comportar e imaginar cenários em que ele poderia falhar na maneira como seu cliente observou . Para cada cenário, tente desenvolver um teste que possa ser executado eficientemente em seu ambiente de teste automatizado atual (isto é, sem precisar de uma nova pilha de VM apenas para este teste), que provaria ou negaria que o código se comporta como esperado que, dependendo do que você esperava, provaria ou desmentiria que esse código é uma possível causa dos problemas dos clientes). Este é o método científico para engenheiros de software; observar, hipotetizar, testar, refletir, repetir.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Não, definitivamente não é. Isso seria uma política estúpida.

O problema que vejo com sua pergunta e sua proposta é que eles não fazem distinção entre

• relatórios de bugs
• falhas ( erros )
• bugs (também chamados de erros )

Um relatório de bugs é uma comunicação sobre um bug. Diz-te que alguém pensa que algo está errado. Pode ou não ser específico sobre o que é suposto estar errado.

Um relatório de bug é uma evidência de falha.

Um falha é um incidente de algo errado. Um defeito específico, mas não necessariamente com pistas sobre o que pode ter causado isso.

Uma falha pode ser causada por um erro.

Um bug é uma causa de falhas; algo que pode (em princípio) ser alterado a fim de evitar que as falhas que ele causa ocorram no futuro.

Às vezes, quando um bug é relatado, a causa é imediatamente clara. Nesse caso, reproduzir o bug seria absurdo. Outras vezes, a causa não está clara: o relatório de erros não descreve nenhuma falha específica, mas a falha é tal que não fornece uma pista sobre qual pode ser a causa. Nesses casos, sinto que seu conselho é justificado - mas nem sempre: não se insiste em bater um segundo foguete espacial de US $ 370 milhões antes de aceitar investigar o que causou o primeiro a falhar (um bug específico no software de controle).

E também há todo tipo de casos entre os dois; por exemplo, se um relatório de bug não provar, mas apenas sugerir, que um problema em potencial que você já conhecia pode ter algum papel, isso pode ser incentivo suficiente para você dar uma olhada nele.

Portanto, embora insistir na reprodutibilidade seja sábio para os casos mais difíceis, não é prudente aplicá-la como uma política rígida.

Como tudo o mais no desenvolvimento de software, a resposta correta é um compromisso.

Em teoria, você nunca deve tentar consertar um bug se não puder provar que ele existe. Isso pode fazer com que você faça alterações desnecessárias em seu código que, no final, não resolvem nada. E provar isso significa reproduzi-lo primeiro, depois criar e aplicar uma correção e depois demonstrar que isso não acontece mais. Seu instinto aqui está direcionando você na direção certa - se você quer ter certeza de que resolveu o problema do seu cliente, você precisa saber o que causou isso em primeiro lugar.

Na prática, isso nem sempre é possível. Talvez o bug só ocorra em grandes clusters com dezenas de usuários acessando simultaneamente seu código. Talvez haja uma combinação específica de operações de dados em conjuntos específicos de dados que acionam o bug e você não tem idéia do que é isso. Talvez seu cliente tenha executado o programa interativamente sem parar por centenas de horas antes do bug se manifestar.

Em qualquer um desses casos, há uma grande chance de que seu departamento não tenha tempo ou dinheiro para reproduzir o bug antes de começar a trabalhar. Em muitos casos, é muito mais óbvio para você, o desenvolvedor, que há um bug no código que aponta você para a situação correta. Depois de diagnosticar o problema, você poderá voltar e reproduzi-lo. Não é o ideal, mas, ao mesmo tempo, parte do seu trabalho como desenvolvedor sênior é saber ler e interpretar códigos, em parte para localizar esses tipos de bugs enterrados.

Na minha opinião, você está se concentrando na parte errada da pergunta. E se você finalmente não puder reproduzir o bug em questão? Nada é mais frustrante para um cliente do que ouvir "sim, sabemos que você caiu no programa, mas não podemos reproduzi-lo, então não é um bug". Quando seu cliente ouve isso, ele o interpreta como "sabemos que nosso software é defeituoso, mas não podemos nos incomodar em consertar e consertar os erros, então cruze os dedos". Se é melhor fechar um bug reportado como "não reproduzível", ou fechá-lo como "não reproduzível, mas fizemos algumas mudanças razoáveis para tentar melhorar a estabilidade"?

A menos que o erro seja evidente, óbvio e trivial, com uma mensagem de erro muito específica, etc., muitas vezes é muito difícil corrigir um erro se o usuário ou o mantenedor não conseguir replicá-lo.

Além disso, como você provaria a eles que o bug será corrigido se você não puder replicar as etapas?

O problema com o seu caso é que o usuário não sabe como o erro ocorreu, ou seja, em qual tela de fazer qual operação. Eles simplesmente têm o log.

Eu acho que seu ponto é razoável. Se você tivesse poderes psíquicos , você possivelmente não estaria trabalhando por um salário.

Acho que você deve dizer aos seus chefes que, sem conseguir replicar o erro, levaria uma quantidade desconhecida de tempo para descobrir, e não há garantia alguma > que você vai.

O problema será quando algum colega de trabalho encontrar o bug sem sorte e consertá-lo.

Vamos ao extremo e presumimos que você encontrou o bug muito antes: em seu código, como você o estava escrevendo. Então você não teria nenhum escrúpulo em corrigi-lo ali - você vê uma falha lógica no código que acabou de escrever, não faz o que você queria que ele fizesse. Você não sentiria necessidade de configurar um ambiente inteiro para mostrar que é realmente um bug.

Agora, um relatório de bug aparece. Há várias coisas que você pode fazer. Uma delas é voltar ao código e relê-lo. Agora, suponha que nesta segunda leitura, você encontre imediatamente o bug no código - ele simplesmente não faz o que você pretendia, e você não percebeu quando o escreveu. E , explica perfeitamente o bug que acabou de chegar! Você faz a correção. Você levou vinte minutos.

Isso corrigiu o bug que causou o relatório de bug? Você não pode ter 100% de certeza (pode ter havido dois erros causando a mesma coisa), mas provavelmente aconteceu.

Outra coisa que você pode fazer é reproduzir a configuração do cliente, assim como pode (alguns dias de trabalho), e eventualmente reproduzir o bug. Em muitos casos, existem problemas de sincronismo e simultaneidade que significam que você não pode reproduzir o bug, mas você pode tentar muito tempo e às vezes ver a mesma coisa acontecer. Agora você começa a depuração, localiza o erro no código, coloca-o no ambiente e tenta várias vezes novamente. Você não vê mais o bug ocorrendo.

Isso corrigiu o bug que causou o relatório de bug? Você ainda não pode ter 100% de certeza - um, você pode ter visto um bug completamente diferente que o cliente fez, dois, talvez você não tenha tentado com frequência suficiente, e três, talvez a configuração ainda seja um pouco diferente e seja fixo neste sistema, mas não no cliente.

Assim, a certeza é impossível em qualquer caso. Mas o primeiro método é muito mais rápido (você pode dar ao cliente um patch mais rápido também), é bem mais barato e, se encontrar um bug de codificação claro que explica o sintoma, é mais provável encontrar o problema também.

Então, isso depende. Se for barato configurar um ambiente de teste (ou melhor: um teste automatizado que mostre o problema), faça isso. Mas se é caro e / ou as circunstâncias em que o erro é imprevisível, é sempre melhor tentar encontrar o erro lendo o código primeiro.

Ao ler a pergunta, não vejo nenhuma oposição fundamental entre sua posição e a de sua equipe.

• Sim, você deve se esforçar ao máximo para reproduzir o problema que ocorre na configuração do cliente. Mas o melhor esforço significa que você deve definir uma caixa de tempo para isso, e pode não haver dados suficientes no log para realmente reproduzir o problema.

  Se sim, tudo depende da relação com esse cliente. Pode ir de você não terá mais nada dele, para o seu pode enviar um desenvolvedor no local com ferramentas de diagnóstico e capacidade de executá-los no sistema com falha. Normalmente, estamos em algum lugar no meio e, se os dados iniciais não forem suficientes, há maneiras de obter mais alguns.

• Sim, um desenvolvedor sênior deve ser capaz de ler o código e é provável que encontre o motivo do problema após o conteúdo do registro. Realmente, muitas vezes é possível escrever algum teste de unidade que exiba o problema depois de ler cuidadosamente o código.

  O fato de escrever tais testes de unidade é quase tão bom quanto reproduzir o ambiente funcional de quebra. Claro, esse método não é uma garantia de que você encontrará alguma coisa. Compreender a sequência exata de eventos que levam ao fracasso em alguns softwares multi-thread pode ser muito difícil de encontrar apenas lendo o código, e a capacidade de depurar ao vivo provavelmente se tornará crítica.

Em suma, eu tentaria as duas abordagens simultaneamente e pediria um sistema ativo exibindo o problema (e mostrando que ele é corrigido posteriormente) ou para algum teste de unidade quebrando o problema (e também mostrando que ele é corrigido após o problema). corrigir).

Tentando consertar o código e enviá-lo em estado selvagem, realmente parece muito arriscado. Em alguns casos semelhantes que ocorreram comigo (onde falhamos em reproduzir o defeito internamente), deixei claro que, se uma correção fosse implementada e não resolvesse o problema do cliente, ou tivesse outras consequências negativas inesperadas, o sujeito que propôs teria que ajudar a equipe de suporte a encontrar o problema real. Incluindo lidar com o cliente, se necessário.

Parece-me que você precisa de um registro mais detalhado.

Embora a adição de mais registros não garanta que você não precisará depurar (ou, neste caso, reproduzir a situação), ele fornecerá uma visão muito melhor sobre o que realmente deu errado.

Especialmente em situações complicadas / de encadeamento, ou qualquer coisa em que você não possa usar um depurador, recorrer a "debug por printf ()" pode ser seu único recurso. Nesse caso, registre o máximo que puder (mais do que você espera precisar) e tenha algumas boas ferramentas para filtrar o trigo do joio.

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Como ninguém disse isso em termos claros ainda: Absolutamente não!

Como tudo o mais no desenvolvimento de software, a correção de erros significa manter em mente o tempo, o risco e o custo. Encontrar um equilíbrio entre eles é metade da descrição do trabalho de um desenvolvedor.

Alguns bugs não são importantes o suficiente para passar 2 dias, mas são importantes o suficiente para gastar 10 minutos para corrigi-los. Outros bugs não são determinísticos e você já sabe que um ambiente de teste não pode provar que eles foram corrigidos. Se a configuração do ambiente de teste levar 2 dias, você não fará isso por esses erros. Em vez disso, você gasta o tempo em coisas mais inteligentes, como encontrar maneiras de configurar um ambiente de teste em cinco minutos, em vez de dois dias.

E, claro, há erros nos quais, se você errar, um cliente perderá $ 100'000 +. E erros nos quais o cliente perderá $ 100'000 + por hora, o bug não foi corrigido. Você precisa olhar para o bug e tomar uma decisão. Declarações gerais para tratar todos os erros não funcionam.

Muito boa pergunta! Minha opinião é que se você não pode reproduzir o problema, então você não pode 100% com certeza dizer que a correção que você fez não irá:

a) realmente corrigir o problema. b) criar outro bug

Há momentos em que um bug ocorre e eu corrijo e não me dou ao trabalho de testá-lo. Eu sei 100% com certeza que funciona. Mas até que nosso departamento de QA diga que está funcionando, considero ainda uma possibilidade de que ainda haja um bug presente ... ou um novo bug criado a partir da correção.

Se você não conseguir reproduzir o bug e, em seguida, instalar a nova versão e confirmar que ela está corrigida, não será possível, com 100% de certeza, dizer que o bug desapareceu.

Eu tentei por alguns minutos pensar em uma analogia para ajudá-lo a explicar aos outros, mas nada realmente me veio à mente. Uma vasectomia é um exemplo engraçado, mas não é a mesma situação: -)

[bug related to] concurrent database access, clustered implementation, multithreaded

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it?

Eu não gastaria muito tempo tentando reproduzi-lo. Isso parece um problema de sincronização e esses são mais frequentemente encontrados por raciocínio (a partir de logs como aquele que você precisa identificar o subsistema no qual o problema ocorre) do que por conseguir encontrar uma maneira de reproduzi-lo e atacá-lo com um depurador. . Na minha experiência, reduzir o nível de otimização do código ou, às vezes, até mesmo ativar a instrumentação adicional, pode ser suficiente para adicionar atraso suficiente ou a falta de primitivo de sincronização para evitar que o bug se manifeste.

Sim, se você não tiver uma maneira de reproduzir o bug, não poderá garantir a correção. Mas se o seu cliente não lhe der a maneira de reproduzi-lo, você também pode estar procurando por algo semelhante com a mesma consequência, mas com uma causa raiz diferente.

Ambas as atividades (revisão de código e teste) são necessárias, nem são suficientes.

Você pode passar meses construindo experimentos tentando reproduzir o bug, e nunca chegar a lugar algum se você não olhar o código e formar uma hipótese para restringir o espaço de busca. Você pode passar meses observando seu umbigo tentando visualizar um erro no código, pode até pensar que encontrou uma, duas, três vezes, apenas para que o cliente cada vez mais impaciente diga: "Não, o bug ainda está lá. "

Alguns desenvolvedores são relativamente melhores em uma atividade (revisão de código vs. construção de testes) do que a outra. Um gerente perfeito pesa esses pontos strongs ao atribuir bugs. Uma abordagem de equipe pode ser ainda mais proveitosa.