Quando você chega de manhã, descobre que seu software não funciona mais, mesmo quando saiu ontem à noite.

O que você faz? O que você verifica primeiro? O que você faz para deixar de ficar com raiva e começar a trabalhar no seu problema? Você culpa seus colegas e vai diretamente a eles? O que pode ser feito para evitar estar em tal situação?

Os suspeitos do costume são:

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

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

• A estação de trabalho foi reiniciada ontem à noite ou uma operação de manutenção noturna limpou os 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 implantada.

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

• Algo mudou na cadeia de compilação: alterações no Makefiles, nova versão do IDE, compilador, bibliotecas padrão ...

1) Se não está funcionando hoje, também não estava funcionando ontem.

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

2) Há um problema, e ele deve ser resolvido .

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

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

Para evitar essa situação, é necessário fazer testes e depuração adequados .

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

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

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

Tentar encontrar alguém para passar a culpa não é 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 fazê-lo funcionar ontem foi apenas sorte, ou algo mudou entre então e agora, e você precisa descobrir o que é é.

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

O uso das 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ódigo que parecia mudar da noite para o dia e, depois de um tempo, cheguei à conclusão de que duendes malévolos entraram na minha base de código à noite e mudaram as coisas de tal maneira que, apesar do fato de ter funcionado ontem, agora não funciona de todo. De fato, no estilo clássico de Schroedinbug , não apenas não funciona agora, mas é claramente claro que não há como isso poderia acontecer.

Com o tempo, percebi que é possível que os duendes não tenham nada a ver com isso e que possivelmente a minha "hora de ir para casa, isso será bom o suficiente" na última versão não receba os testes detalhados e a atenção que talvez mereça .

Minha primeira suposição, quando encontro isso pela manhã, é que provavelmente é minha culpa, já que geralmente sou responsável por meus próprios recursos ou cantos do software em que estou trabalhando. Minha segunda suposição é que eu poderia muito bem tomar esse café agora. Se não é algo óbvio que um macaco possa descobrir (o que às vezes é), então há boas chances de eu ter conseguido arrastar uma versão antiga de uma biblioteca, revertendo por engano um arquivo que não precisava ser revertido de volta ou tenha algo armazenado em cache em algum lugar que o trouxe para a compilação sem verificar. Passar por minha atividade recente de Controle de Origem tende a revelar coisas que eu fiz, a limpeza da compilação geralmente remove versões em cache incorretas.

Às vezes, realmente 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; existem muitas possibilidades de fundo, mas geralmente é um caso de aceitar e aceitar que, como a maioria das pessoas, sou basicamente um idiota.

Use o controle de versão. Faça uma diferença 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, 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ê poderá observar as datas de alteração dos arquivos e, possivelmente, verificar os recursos de registro do sistema operacional.

Além disso: recompile tudo, recompile também as bibliotecas auxiliares.

Obviamente: se você encontrou a fonte do erro, mantenha a calma, pergunte por que uma alteração foi feita, explique seu problema e proponha uma solução que faça os dois felizes. Não grite com ela, isso seria veneno para sua produtividade.

Se não houver alterações, é hora de ver o que mudou no sistema. Por exemplo, recentemente, os computadores Mac OS foram atualizados para uma nova versão do Apache, que resultou em 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 extrai 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. Também teria funcionado 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 ...

Portanto, minha resposta à sua pergunta sobre o que verificar primeiro é verificar novamente como você formata suas datas, porque se você misturar os campos dia e mês, ele funcionará perfeitamente, mas apenas um dia por mês :-)

Corrija o erro (como normalmente faz). Então, se você descobrir quem o causou, envie um e-mail educado, informando o que deu errado.

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

É apenas se você suspeitar que eles são descuidados com regularidade 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 para de funcionar é se perguntar: o que é diferente? O que mudou?

Quando algo funcionou ontem à noite, mas falhou esta manhã, a única coisa que obviamente mudou é - a data e a hora :)

Eu tentaria pensar se existe alguma parte da lógica na qual estou trabalhando que depende das datas e pode ser afetada pela passagem do tempo. É surpreendente quantas vezes essa é a causa de tais problemas.

Se isso falhar, você deve definitivamente seguir os outros bons conselhos fornecidos aqui.

Uma resposta curta (para escrever), mas longa para entender o essencial: 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 na sua caixa de correio os emails enviados pelo mecanismo de Integração Contínua quando os testes de unidade falharam (ou a página de log, se você não observou esse problema específico) e vê quem fez o check-in imediatamente antes da compilação .

Então vá falar com ele ou ela.

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

Olhe para os dados

Há algo nos dados que você não testou e / ou não considerou. 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ê com dados válidos.

Certa vez, tive um código de entrada de pedido funcionando bem por semanas. Fui para casa um dia e ele morreu. A investigação no dia seguinte revelou que eu tinha um bug oculto em uma cadeia de chamadas de função. Em uma linguagem de tipo fraco, declarei um número inteiro quando deveria ter usado um int longo. O idioma fez a conversão entre os dois automaticamente até que não pudesse, porque o número excedia o que caberia em um número 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 apresentou uma atualização do sistema operacional? Outro codificador modificou o código usado pelo seu programa? A permissão do usuário mudou? Frequentemente, se você encontrar o que mudou, encontrará o bug.

Costeleta binária

funciona especialmente bem para erros difíceis de JavaScript. Basicamente, comente metade do código, veja se você recebeu o erro; se o fizer, está nessa metade do código. Metade novamente e continue.

Se o seu código estiver bem encapsulado, é uma ferramenta fantástica, que economiza tempo e reduz o estresse.

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

E, claro, o que pode ser feito para evitar estar em tal situação?

Dirigindo-se a essa pergunta, convém examinar a Integração Contínua (IC) . Simplificando: o CI é um processo no qual os desenvolvedores freqüentemente (várias vezes ao dia) integram e testam todo o código. A idéia é que as alterações em um módulo que quebram outro módulo sejam encontradas rapidamente.

Na prática, a maioria das equipes que empregam IC usa um servidor CI (consulte: lista da Wikipedia ). O servidor de CI geralmente é configurado para monitorar o repositório SCM e iniciar uma construção quando houver alterações. Quando a compilação estiver concluída, ele executará uma série de testes automatizados e publicará os resultados por email e / ou página da web da compilação e testes, juntamente com as alterações que causaram a compilação. Felizmente, quando algo quebra a compilação ou os testes, você tem apenas uma alteração muito pequena para analisar, para que seja resolvida mais rapidamente.

Há outras perguntas aqui sobre qual servidor de CI usar, então deixarei você encontrá-las interessadas. Pessoalmente, sou um grande fã de Jenkins.

[O que devo fazer sobre as coisas serem quebradas.]

Como outros já disseram, descubra o que quebrou e tente consertá-lo. Gastar tempo tentando culpar é o tempo gasto para não resolver o problema.

Minha reação natural é sempre culpar os outros, mas, com o tempo, percebi que geralmente sou 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 é compartilhado com outros membros da equipe, um Twiki privado, Evernote, um diário de bordo ou uma boa memória. O importante, no momento em que você encontra a resposta (e deseja voltar ao trabalho!), É registrar o motivo.

Presumivelmente, se ele não estiver mais funcionando, você identificou os sintomas de que não está funcionando, ou seja, trava ou retorna uma caixa de diálogo de erro específica ao usuário.

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

Então você começa a procurar possíveis causas, através de logs ou tentativa de recuperação do problema ou uma combinação de ambos - depende de como seu sistema está configurado, eu acho.

Então você começa a descartá-los.

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

Mais a sério, eu primeiro diria a eles:

• Vou olhar para ver o que há de errado e o que poderia ser a raiz

• Vou tocar a base daqui a 30 a 60 minutos, quando 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 corrigi-lo, se ainda não estiver corrigido e, se aplicável, quais dados podemos ter perdido (mas tenho bons backups, para que nunca aconteça esperançosamente).

Quanto à parte culpada:

• se é apenas um erro de digitação de um colega, não há necessidade de mencionar: a merda acontece e o medo do bug provavelmente lhe ensinou uma lição e, esperançosamente, ele não fará isso de novo.

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

Se seus métodos habituais de rastreamento de erros não funcionarem e tudo estiver totalmente confuso, pode ser maravilhoso ter um backup que você possa restaurar facilmente.

É o que eu corro localmente, automaticamente a cada hora, das 8h às 18h:

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

Simples, né?

Se você precisar restaurar alguma coisa, use

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

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

Obviamente, esse não deve ser o 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 erros, mas se tudo mais falhar, é um fallback.

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

Isso aconteceu comigo. Um bug desenvolvido entre duas versões do nosso projeto. Literalmente, a única alteração que fizemos foi atualizar para uma versão mais recente de uma das bibliotecas subjacentes.

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. Concordei que isso não deveria ter quebrado o sistema.

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

estava funcionando ontem, pois estava sendo usado corretamente.

você descobre que outras pessoas usam as coisas de uma maneira que não supõe que seja uma boa maneira de quebrar coisas.

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

Cópia de segurança!

Acho muito útil definir pontos de interrupção para pausar e verificar meus dados, para identificar exatamente onde e como estão as coisas estão ruins.