Dicas para depuração com muito pouca informação? [fechadas]

Eu herdei um projeto com uma base de código bastante grande e o desenvolvedor original raramente, se é que alguma vez responde a e-mails. Existem várias maneiras diferentes de fazer algumas coisas, e eu não conheço todas elas. Muitos códigos duplicados ao longo desses caminhos (em vez de funções incluídas por, digamos, 5 páginas que fazem relativamente a mesma coisa, seu código é copiado em 5 páginas) e alguns problemas sutis no banco de dados (todos já ouvimos falar em código espaguete , mas você já ouviu falar de um banco de dados de espaguete?)

Tudo isso eu posso lidar com a maior parte do tempo sem problemas.

O problema é quando um cliente encontra um bug em algum lugar. Eles geralmente enviam uma captura de tela da edição final e dizem: "Você pode dar uma olhada nisso?" destacando o item específico da página que está errado e, às vezes, o que era esperado. Muito pouco mais informação é fornecida, e tentar conversar com eles e obter mais (como o que eles fizeram para obter o resultado) é como arrancar dentes.

Basicamente, tudo se resume a isso:

• Base de código grande e complexa com a qual não estou 100% familiarizado
• Muitas maneiras pelas quais as coisas podem dar errado
• Pouca informação sobre como um bug surgiu

Alguém tem dicas, truques, sugestões etc. sobre como depurar esse tipo de coisa?

Quando recebo algo assim, geralmente exijo mais informações. Não sei como é o local onde você trabalha, mas aqui, se eu não tiver informações suficientes para reproduzir o problema localmente, posso enviar o tíquete de volta marcado como Não é possível reproduzir, com um pedido de mais informações, e eles sabem que nada será corrigido até Eu sou capaz de quebrá-lo do meu lado.

Se seus clientes estiverem com problemas para descrever as etapas, peça um vídeo de captura de tela. Existem alguns produtos gratuitos que podem ser criados, como o Jing. Isso torna muito mais fácil quando você pode assistir exatamente o que eles estavam fazendo.

Edição: Jing foi uma boa idéia quando eu escrevi isso há alguns anos atrás. Desde então, eles modificaram o instalador para carregar seu sistema com crapware "bônus" que você nunca pediu, por isso não posso mais recomendá-lo. No entanto, existem muitos gravadores de tela decentes.

Um bom começo pode ser este livro .

Estou usando a definição abaixo, pois parece que o desenvolvedor não está mais disponível para suportá-lo.

Código legado é o código-fonte que se refere a um suporte não mais suportado.

Eu tive um problema semelhante há alguns anos e o maior aumento na produtividade e na limpeza de código foi a integração do rastreamento de erros no sistema.

Usamos o Fogbugz (suponho que eles ainda façam o Fogcreek!) E fomos capazes de criar um mecanismo de tratamento de exceções no qual o usuário pudesse pressionar um botão a qualquer momento que surgisse uma exceção e seria imediatamente conectado ao sistema - sem mais chamadas e não há mais capturas de tela. Com essa opção, você obtém as informações necessárias em vez de tentar extraí-las do usuário. Parece uma variante para você, especialmente com uma opção de captura de tela.

A outra coisa que você deseja iniciar é começar a adicionar o log. Você pode ir até o registro de cada chamada de método com valores de argumento. Como parece que você está trabalhando com código legado (código sem testes), esse registro o ajudará a adicionar testes de unidade apropriados para que você não repita nenhum problema.

Meu conselho mais sincero é começar a refatorar onde puder. Não consigo contar o número de vezes em que vi uma recopia de funcionalidade apenas para descobrir que não era 100% uma cópia completa. Foi uma cópia de 99,9% e um pequeno erro menor que resultou em um bug. Comece a adicionar testes de unidade a tudo e, se você tiver um departamento de controle de qualidade, tente obter alguns scripts de teste automatizados para essas partes do código em que você está trabalhando.

Por outro lado, veja quanto log pode injetar no código. Ou seja, se não houver muito em termos de registro, você pode adicionar um sinalizador ao código para começar a selecionar registros mais detalhados para seus próprios fins de depuração. Isso é algo que você pode ativar e desativar um usuário, se você conseguir abrir uma caixa de diálogo. Isso me ajudou mais vezes do que posso contar. Normalmente recebo "não funciona" sem uma imagem do problema. Eu apenas digo "envie-me o arquivo de log".

Comece escrevendo testes de unidade. Escolha uma classe ou uma função e escreva um conjunto de testes correspondente a como você acha que deve funcionar. Se os testes falharem, descubra o porquê. Se for um bug - corrija-o. Se suas expectativas estiverem erradas, descubra o que a coisa realmente faz e modifique os testes de acordo.

Depois de ter um conjunto decente de testes de unidade de trabalho, você tem uma rede de segurança para fazer alguma refatoração para tornar o código mais limpo.

Continue iterando até entender a base de código.

Escusado será dizer que isso é algo que você deve fazer antes do tempo, não em resposta a um relatório de bug.