Os suspeitos do costume são:

• Você achou que funcionou ontem, mas depois de um dia cheio de trabalho você estava cego demais para perceber que não funcionava.

• Esta manhã, você não pode mais se referir ao que estava na memória cache IDE ontem.

• A estação de trabalho foi reinicializada na noite passada ou uma operação de manutenção noturna foi limpa nos diretórios / tmp.

• Algo mudou na base de código: verifique se alguém (possivelmente você mesmo) cometeu alterações entre sua última compilação de ontem e sua última compilação de hoje.

• Algo mudou nas bibliotecas de suporte: verifique se essas bibliotecas foram recompiladas ou atualizadas. A causa pode estar dentro do projeto para bibliotecas específicas ou fora, se uma nova versão de um pacote aparentemente independente tiver sido implementada.

• Algo mudou no ambiente de teste: nova versão de uma máquina virtual, um stub que foi modificado, alterações em um servidor de banco de dados remoto ...

• Algo mudou na cadeia de compilação: mudanças em Makefiles, nova versão do IDE, do compilador, de bibliotecas padrão ...

1) Se não estiver funcionando hoje, também não funcionou ontem.

Você pensou que estava funcionando, mas não estava.

2) Existe um problema e deve ser resolvido .

Não pense em quem é responsável por isso ou por culpar os outros.

Se nada mudou entre ontem e hoje (como eu presumo ler sua pergunta), isso significa que você deve fazer um trabalho melhor em testar seu código antes de realmente declarar que está funcionando.

Para evitar essa situação, você precisa fazer os Testes e Depuração adequados.

Defina "trabalhando" e teste os limites de suas rotinas de código.

• Tente se tornar um dos usuários que usarão suas funcionalidades de código ou programa.
  
• Envie seu código para os limites permitidos e além, e realmente verifique se ele quebra.

Uma maneira de fazer isso é ter um conjunto automatizado de testes extensivos executados durante a noite, para que no dia seguinte você possa verificar se algo deu errado e corrigir os problemas.

Tentar encontrar alguém para passar a culpa é pouco construtivo e não resolve problemas. Não faça isso.

Se algo funcionou ontem e não funciona agora, então você tem um comportamento não-determinístico (como uma condição de corrida) e tê-lo funcionando ontem foi apenas sorte, ou algo mudou entre então e agora, e você precisa encontrar o que é isso.

Como exatamente você descobre qual é o caso e como ele pode ser corrigido depende das especificidades da situação, mas sempre ajuda ser metódico na eliminação de causas, ou seja, não altere 5 coisas de uma só vez e pare de procurar se que ajuda - descubra qual coisa específica causou o problema e, talvez, anote como consertá-lo para que você possa consultá-lo quando isso acontecer novamente daqui a 3 semanas.

Usar as ferramentas de diagnóstico apropriadas (depurador, profiler, ferramentas de análise de rede) também pode fazer uma grande diferença.

Eu trabalhei com códigos que pareciam mudar durante a noite e depois de um tempo cheguei à conclusão de que isso era devido a pixies malevolentes rastejando em minha base de código à noite e mudando as coisas de tal forma que apesar de ter funcionado ontem , agora não funciona de todo. De fato, no estilo clássico do Schroedinbug , não apenas não funciona agora, como é evidente, não há que poderia ter.

Com o tempo eu percebi que é possível que na verdade os duendes não tenham nada a ver com isso e que possivelmente minha "hora de ir para casa, que seja boa o suficiente" na última construção não tenha os testes detalhados e atenção que talvez mereça.

Às vezes, não tem nada a ver comigo - alguém atualizou uma dependência sem mencioná-la, o WindowsUpdate instalou algo que mudou o ambiente para que meu código não funcionasse; há muitas possibilidades de experiência, mas geralmente é um caso de se casar e aceitar que, como a maioria das pessoas, eu sou basicamente um idiota.

Use o controle de versão. Faça um diff ou use a funcionalidade de culpa do seu VCS.:

• diff : Todo VCS. Mostra as diferenças de, uhm, versões diferentes
• blame : por exemplo git. Mostra você linha por linha quem mudou o que

Se não houver controle de versão, além de ser culpa sua ou do seu chefe, você pode verificar as datas de alteração dos arquivos e, possivelmente, verificar os recursos de registro do sistema operacional.

Além disso: Recompile tudo, certifique-se de recompilar as bibliotecas auxiliares.

Claro: se você encontrou a fonte de erro, fique calmo, pergunte por que uma mudança foi feita, explique seu problema e proponha uma solução que faça você feliz. Não grite com ela, isso seria veneno para a sua produtividade.

Se não houver mudanças, é hora de ver o que mudou no sistema. Por exemplo, recentemente os computadores Mac OS foram atualizados para uma nova versão do Apache, o que gerou algumas configurações inválidas.

Bem, aqui está um exemplo real de código que "funcionou ontem" e não hoje ... É do início deste mês.

O aplicativo em questão puxa informações de um banco de dados por data e o comportamento padrão é obter dados para o dia atual. Isso funcionou bem em 8 de agosto, mas falhou no dia 9. Não foi testado antes disso. Teria também trabalhado em 9 de setembro e 10 de outubro ...

Outra pista é que estamos no Reino Unido, o banco de dados em questão estava nos EUA ...

Assim, a minha resposta à sua pergunta sobre o que verificar primeiro é verificar como você formata as datas, porque se você misturar os campos de dia e mês, funcionará perfeitamente, mas apenas 1 dia por mês: - )

Corrige o bug (como você normalmente faz). Então, se você encontrar quem causou, envie um e-mail educado para que saibam o que deu errado.

Todo programador comete erros e, se você começar a culpar, ele será seriamente contraproducente na próxima vez que você fizer a mesma coisa. (possivelmente até esse bug foi seu)

É só se você suspeitar que eles são descuidados se você fizer um grande negócio com alguns bugs.

... você executa testes de regressão e se concentra naqueles que falham.

Na verdade é o que você esqueceu de fazer ontem antes de sair, acontece.

Você não tem nenhum? Ok, o que você está dizendo? Culpando ? Bem ... isso pode funcionar, então

A primeira coisa a fazer quando algo deixa de funcionar é perguntar a si mesmo - O que é diferente? O que mudou?

Quando algo funcionou na noite passada, mas falha esta manhã, a única coisa que obviamente mudou foi - a data e a hora :)

Eu tentaria pensar se há alguma parte da lógica em que estou trabalhando, que depende de datas e pode ser afetada pela passagem do tempo. É surpreendente quantas vezes é a causa de tais problemas.

Se isso falhar, você deve definitivamente seguir o outro grande conselho fornecido aqui.

Uma resposta meio curta (para escrever) mas meio longa para entender a essência: Por que os programas falham: um guia para Depuração Sistemática de Andreas Zeller (que pode parecer um pouco acadêmico, mas não é)

Você procura em sua caixa de correio após o email enviado pelo mecanismo Continuous Integration quando os testes de unidade falharam (ou a página de log se você não assistiu a esse problema específico) e ver quem fez o check-in apenas antes dessa construção.

Depois, fale com ele ou ela.

Existem apenas duas razões possíveis para o seu código falhar hoje, mas funcionou ontem.

Veja os dados

Há algo nos dados que você não testou nem contabilizou. Os dados não são validados corretamente ou um erro na lógica não foi revelado até que ocorra uma condição lógica que você não previu. Isso significa que o bug estava lá ontem, mas estava escondido de você sob dados válidos.

Uma vez eu tive algum código de entrada de pedido funcionando bem por semanas. Eu fui para casa um dia e ele morreu. Investigação no dia seguinte revelou que eu tinha um bug escondido em uma cadeia de chamadas de função. Em uma linguagem fracamente tipada, declarei um inteiro quando deveria ter usado um longo int. O idioma fez a conversão entre os dois automaticamente até que não pudesse, porque o número excedeu o que caberia em um inteiro. O sistema falhou no número de pedido 32768.

Veja o que mudou

Veja o que mudou desde que funcionou. A seção de TI enviou uma atualização do sistema operacional? Um outro codificador modificou o código que seu programa usa? A permissão do usuário mudou? Muitas vezes, se você encontrar o que mudou, você encontrará o bug.

Chop binário

funciona especialmente bem para erros de JavaScript difíceis. Basicamente comentar metade do código, veja se você receber o erro, se você fizer isso é nessa metade do código. Metade novamente e continue.

Se o seu código estiver bem encapsulado, esta é uma fantástica ferramenta de economia de tempo e de redução de stress.

Depois de encontrar o código culpado, geralmente vale a pena isolar o erro em sua própria página de teste.

And of course, what can be done to avoid being in such a situation?

Respondendo a essa pergunta, convém examinar Integração contínua (IC) . Simplificando: o CI é um processo em que os desenvolvedores frequentemente (várias vezes ao dia) integram e testam todo o código. A ideia é que as mudanças em um módulo que quebram outro módulo sejam encontradas rapidamente.

Na prática, a maioria das equipes que emprega o IC usa um servidor de IC (consulte: lista da Wikipédia ). O CI Server geralmente é configurado para monitorar o repositório SCM e iniciar uma compilação quando ele vê as alterações. Quando a compilação estiver concluída, ela executará uma série de testes automatizados e publicará os resultados por e-mail e / ou página da Web da compilação e dos testes, juntamente com as alterações causadas pela compilação. Com sorte, quando algo quebra a compilação ou os testes, você tem apenas um pequeno conjunto de mudanças para analisar, então ele é resolvido mais rapidamente.

Há outras perguntas aqui sobre qual servidor de IC usar, portanto, permitirei que você as encontre interessadas. Pessoalmente, sou um grande fã de Jenkins.

[What should I do about things being broken.]

Como outros já disseram, descubra o que quebrou e tente consertá-lo. Gastar tempo tentando colocar a culpa é tempo gasto não resolvendo o problema.

Minha reação natural é sempre culpar os outros, mas com o tempo eu percebi que é geralmente eu quem é o culpado. Além de todos os excelentes comentários acima, é importante que você registre por si mesmo qual foi o motivo final. Não importa se você usa um Wiki que seja compartilhado com outros membros da equipe, um Twiki privado, o Evernote, um livro de registro ou uma boa memória. O importante, no momento em que você encontra a resposta (e quer voltar ao trabalho!) É registrar o motivo.

Presumivelmente, se ele não estiver mais funcionando, você identificou os sintomas dele não funcionando, isto é, trava ou retorna um diálogo de erro específico para o usuário.

Se a única descrição do problema é "não está funcionando", a primeira coisa que você precisa fazer é coletar mais informações sobre os sintomas do problema.

Depois, você começa a procurar por possíveis causas, seja por meio de registros ou por tentativa de recriação do problema, ou por uma combinação de ambos - depende de como seu sistema está configurado, eu acho.

Então você começa a excluí-los.

Isso é o que geralmente acontece quando eu tiro férias: -)

Mais seriamente, eu diria primeiro:

• Analisarei para ver o que está errado e o que pode ser a raiz

• Vou tocar na base em 30 a 60 minutos depois que tiver a chance de ver o que está acontecendo

Após esse período, posso arriscar uma estimativa do que pode ter acontecido e quanto tempo levará para consertá-lo, se ele não estiver corrigido e, se aplicável, quais dados podemos ter perdido (mas eu tenho bons backups, então isso nunca acontece, esperançosamente).

Quanto à parte culpada:

• se for apenas um erro de digitação de um colega, não há necessidade de mencioná-lo: a merda acontece e o medo do bug provavelmente lhe ensinou uma lição e, esperamos, ele não fará isso novamente.

• se ele fizesse algo que eu dissesse a ele (por exemplo, forneça a senha de root do servidor de produção para o novo cara e diga a ele para fazer uma modificação diretamente sem supervisão) (sim, isso já aconteceu). ..), então eu tenho que mencionar isso.

Se os seus métodos usuais de rastreamento de erros não funcionarem e tudo for uma bagunça total, pode ser maravilhoso ter um backup que você possa restaurar facilmente.

Isso é o que executo localmente, automaticamente a cada hora, das 8h às 18h:

rdiff-backup /path/to/mystuff /path/to/mybackup

Simples, eh?

Se você precisar restaurar alguma coisa, use

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup armazena apenas arquivos que diferem. Você pode usar o rdiff-backup no Linux, mac e win.

Claro, isso não deve ser seu único backup. Mas é uma maneira extremamente fácil e barata de ter um backup local.

Agora, eu não recomendaria isso como um método normal de correção de bugs, mas se todo o resto falhar, é uma alternativa.

O bug pode já ter existido, mas foi ocultado por fatores externos ou problemas profundos no sistema.

Isso aconteceu comigo. Um bug desenvolvido entre 2 builds do nosso projeto. Literalmente, a alteração somente que fizemos foi atualizar para uma compilação mais recente da biblioteca subjacente.

Naturalmente nós os culpamos. Mas a única mudança que eles fizeram foi refatorar alguns cabeçalhos para uma compilação mais rápida. Eu concordei que isso não deveria ter quebrado o sistema.

Depois de muita depuração, descobriu-se que o problema era um bug de ponteiro nocivo que estava latente no meu código para anos . De alguma forma, isso nunca foi acionado até que a refatoração alterasse o arranjo do executável.

estava funcionando ontem, como estava sendo usado corretamente.

você descobre que outras pessoas usam as coisas de uma maneira que não é uma boa maneira de quebrar coisas.

é sempre bom atualizar o código no início do dia, pois isso deixa você com um bom ambiente de teste.

Backup!

Acho que definir pontos de interrupção para pausar e verificar meus dados é muito útil, para identificar exatamente onde e como está indo mal.