Há um excelente livro que li sobre esse assunto chamado Por que os programas falham , que descreve várias estratégias para encontrar bugs, desde a aplicação do método científico para isolar e resolver um bug até a depuração delta. A outra parte interessante deste livro é que ele acaba com o termo 'bug'. A abordagem de Zeller é:
(1) Um programador cria um defeito no código. (2) O defeito causa uma infecção (3) A infecção se propaga (4) A infecção causa uma falha.
Se você deseja aprimorar suas habilidades de depuração, recomendo este livro.
Em minha própria experiência pessoal, encontrei muitos bugs em nosso aplicativo, mas o gerenciamento simplesmente nos pressiona para obter novos recursos. Eu sempre ouvi "Nós encontramos esse bug e o cliente ainda não o percebeu, então deixe-o até que o façam". Eu acho que ser reativo em vez de proativo na correção de bugs é uma péssima idéia, pois quando chega a hora de corrigir, você tem outros problemas que precisam ser resolvidos e mais recursos de gerenciamento querem sair o mais rápido possível, para que você seja pego em um ciclo vicioso que pode levar a uma grande quantidade de estresse e esgotamento e, finalmente, a um sistema dominado por defeitos.
A comunicação também é outro fator quando erros são encontrados. Enviar e-mail ou documentá-lo no rastreador de bugs é ótimo, mas na minha própria experiência, outros desenvolvedores encontram um bug semelhante e, em vez de reutilizar a solução que você colocou para corrigir o código (como eles se esqueceram disso) ), eles adicionam suas próprias versões, então você tem 5 soluções diferentes em seu código e, como resultado, parece mais inchado e confuso. Portanto, quando você corrigir um bug, certifique-se de que algumas pessoas revisem a correção e forneçam feedback caso tenham corrigido algo semelhante e encontrem uma boa estratégia para lidar com ela.
limist mencionou o livro The Pragmatic Programmer, que tem algum material interessante sobre a correção de bugs. Usando o exemplo que eu dei no parágrafo anterior, eu veria o seguinte: Software Entrophy , onde a analogia de uma viúva quebrada é usada. Se duas janelas quebradas aparecerem, sua equipe poderá ficar apática por consertá-la, a menos que você tome uma atitude proativa.