O software travou, como resolver?
A solução para o problema é prescrever o remédio certo. O mesmo é verdadeiro para travamentos de software. Precisamos encontrar a causa do acidente. Para travamentos de software, como localizamos o problema? Esta é a pergunta que você fez hoje.
É muito útil ver, cheirar e perguntar na medicina chinesa. Para a investigação e análise de problemas de software, você também pode ver, ouvir e perguntar.
Um, espero
Esperança é observar o fenômeno. O chamado fenômeno de observação é observar seu funcionamento. Como o software funciona, como ele trava e quais são as dicas do travamento. Esses são fenômenos de colapso superficiais e podem ser vistos intuitivamente. Nesse nível, precisamos apenas observar fenômenos operacionais básicos e coletar descrições relevantes. Claro, não é apenas uma questão de assistir ao colapso. Devemos pelo menos compreender estas condições: sistema operacional, permissões operacionais, procedimentos operacionais de software, avisos de erro de falha, fenômenos de falha, etc. Essas situações podem parecer simples, mas fornecem a base mais básica para erros de posicionamento.
Exceto aqueles que são muito experientes, ou aqueles que conhecem seu próprio software, eles podem saber o problema olhando. Como o software terá esses problemas antes, você pode localizar o problema diretamente. Para pessoas de nível médio, ou o software é realmente complicado, é difícil saber a causa à primeira vista. Isso também é normal. Esta etapa é coletar mensagens de erro básicas e intuitivas, e é isso.
Esta etapa não pode ser realizada apenas olhando para ele novamente. No final, resolvido ou não, ainda é necessário observar através desta etapa, pelo menos para eliminar os sintomas na superfície. Se todos os sintomas corresponderem um a um com os problemas encontrados, a explicação é razoável e razoável, os sintomas desaparecem após a resolução e os sintomas são restaurados novamente, para que você possa ter certeza de que o problema foi realmente encontrado, pelo menos em termos dos sintomas.
Além disso, em muitos casos, não basta fazer uma única vez, é preciso deixar o software morrer indefinidamente e observar a lei a partir desse processo. Este também é um meio de coletar fenômenos. Há apenas um fenômeno em uma única operação. Quando um grande número de fenômenos converge, um fenômeno regular é formado. Nesse momento, os problemas podem ser mais aparentes. Por exemplo, um programa que gera números aleatórios, uma ou duas vezes, pode apenas pensar que o número aleatório nunca é maior que 10, e você acha que isso é normal. Mas, por meio de muitos experimentos, o resultado nunca foi maior que 10, e o intervalo definido no início é de 0 a 100. Deste ponto de vista, pode haver um problema. Então, pela análise desse fenômeno, de acordo com a teoria da probabilidade estatística, definitivamente não é normal que tenha sido menor que 10. Se você testar apenas algumas vezes, esse problema será difícil de descobrir. Este é o problema da regularidade.
Em segundo lugar, cheire
Cheirar é ouvir o som. A chamada escuta do som é porque você não pode vê-lo diretamente. Portanto, você precisa procurar mais por sintomas. Observe que aqui ainda está procurando por sintomas. Ele está apenas procurando um pouco mais fundo. O som não é a compleição superficial, é invisível. No software, correspondemos às condições operacionais de memória, CPU, disco, etc. Muitas questões complexas muitas vezes não são óbvias na superfície. Neste momento, precisamos ouvi-lo. Não é exagero dizer que às vezes até ouvimos sons, como o som do disco rígido girando, o som da ventoinha e assim por diante. A alteração da velocidade de rotação do disco rígido pode ser causada por leitura e gravação anormais do programa, o que pode causar velocidade de rotação irregular, ou um loop infinito de leitura e gravação de discos, que fará com que o disco rígido gire loucamente. Claro, este é um disco rígido mecânico. Se estiver sólido, podemos sentir a temperatura. A loucura do ventilador pode ficar presa em um loop infinito, fazendo com que a CPU execute cálculos de longo prazo com alta complexidade computacional e gere muito calor.
Citar esses exemplos não é pedir que você faça isso, é claro que às vezes precisa ser feito. Especialmente para desenvolvimento de hardware, isso é muito comum. Por exemplo, você deve cheirar se a placa de circuito está queimada. Mais frequentemente, os problemas de software raramente envolvem as operações acima.
O que estamos falando aqui é mais de um nível mais profundo de observação. Porque o fenômeno da superfície não foi capaz de analisar o problema. Geralmente começamos a observar a partir da situação da memória, uso da CPU, leitura e gravação do disco rígido. Através do uso da CPU, é possível analisar loops mortos, recursão morta, etc. A leitura e gravação do disco rígido podem analisar o problema de travamento da leitura e gravação do arquivo. O problema de memória usa muito a memória, o que faz com que a memória do sistema caia em um estado de memória indisponível e, finalmente, faz com que todo o sistema trave. Já encontrei e resolvi isso antes.
Então, como olhar para ele, a ferramenta mais simples é o gerenciador de tarefas. Claro, existem muitas ferramentas mais poderosas que podem analisar threads de processo, bibliotecas dinâmicas, bloqueios e outras coisas mais avançadas. Por exemplo, algumas ferramentas podem analisar o problema de deadlock e fazer com que o software seja eliminado pelo sistema. Então, a profundidade da análise depende do nível de conhecimento do indivíduo. Se você nem sabe qual é o processo, não pense em ser capaz de operar essas ferramentas avançadas. E o processo dessas análises ainda requer mais prática e resumo por você mesmo. Não há experiência na cura de todas as doenças, apenas a prática é a melhor ferramenta.
Tres pergunte
Perguntar é perguntar sobre os sintomas. Se o seu software é usado por usuários, as informações que você coletou nas duas primeiras etapas são realmente limitadas. Mesmo que o usuário grave a tela, ainda não é suficiente, então você precisa perguntar a situação.
É necessário inquirir. Ao mesmo tempo, há um lugar para se prestar atenção, que é começar pelo lugar mais idiota e básico. Por exemplo, o usuário não tem uma rede e, em seguida, inicia seu programa, seu programa não considera esse problema e, em seguida, pensa diretamente que há uma rede e, em seguida, desliga, gerando uma exceção de rede. E você não pensou nisso com antecedência, então cometeu um erro. Se você não perguntar primeiro a conexão de rede do computador do usuário, você apenas pergunta muito e pode não encontrar o problema. Isso também pode ocorrer porque você não tem certeza sobre a rede.
Pedir aos usuários é compensar o fenômeno de que você não pode coletar os problemas diretamente. Claro, perguntar aos usuários não é o foco de nossa discussão aqui. Devíamos estar perguntando sobre computadores. Você acha incrível perguntar ao computador? O computador não pode falar. Esta é a comunicação humano-computador e é uma habilidade necessária para os programadores.
A chamada pergunta ao computador é, na verdade, para se comunicar ativamente com o computador para ver quanta informação o computador pode lhe fornecer. Contanto que você seja bom o suficiente, qualquer computador que você pedir fornecerá qualquer informação. Para ser franco, significa fazer testes condicionais. Esta é uma observação ativa. Por meio do teste de simulação de diferentes situações, obtém-se as informações correspondentes e, em seguida, o fenômeno é analisado ao contrário. Isso vai além com base na esperança. Freqüentemente, o posicionamento de muitos problemas de software é resolvido perguntando ao computador.
Os métodos usados são: teste de comando do console, configuração do sistema de alternância, alternância entre sistemas operacionais diferentes, execução com permissões diferentes, simulação de modos operacionais diferentes, uso de IDs de usuário diferentes, e assim por diante. Existem muitas maneiras de fazer isso. Mais é fazer testes e observações direcionados com base nas características de seu próprio software.
Quatro, corte
Corte é para obter o pulso. Por meio da investigação aprofundada acima, uma grande quantidade de informações será inevitavelmente coletada.Se o diagnóstico não puder ser confirmado, então devemos continuar em profundidade. A última etapa é obter o pulso. O pulso é um código. Usamos fenômenos para localizar o escopo aproximado do código, depois analisamos cuidadosamente o fluxo do código e, em seguida, conduzimos um grande número de testes para analisar o fenômeno ou modificamos temporariamente o código para operação de teste, estreitando lentamente o escopo do problema e finalmente localize o problema.
O código é o impulso do programa e o código é a alma do programa. As ferramentas e métodos de depuração de erros no código, acredito que cada IDE fornece uma ferramenta poderosa. Então eu não falo sobre isso. Devemos fazer bom uso de todas as ferramentas de depuração em nossas mãos para nos permitir saber mais sobre o funcionamento do programa.
Por fim, fale sobre como melhorar a eficiência da solução.
1. Colete fenômenos suficientes
Sem fenômenos suficientes, é difícil localizar o problema. Quanto mais preciso o problema, mais rápido ele pode ser localizado. Quanto mais você entende o fenômeno do problema, com mais precisão você pode localizar o local do problema. Se houver poucos fenômenos, a meta será muito ampla, de modo que a eficiência da resolução será naturalmente baixa. Como coletar perguntas foi descrito em detalhes acima.
2. Mantenha a calma pensando o suficiente
O pensamento calmo é muito importante. Quanto mais urgente for o problema, mais pensamento calmo será necessário. Pensar com calma não significa que você não está com pressa. Somente pensar com calma pode encontrar pistas em muitos fenômenos.
3. Pensamento divergente, quebre o impasse do pensamento
O impasse de pensamento costuma ser o inimigo natural que encontra o maior problema. Se você está sempre confuso com um problema, lembre-se de sair desse estado a tempo. Você pode colocar o problema de lado primeiro, dar dois passos ou beber chá. Freqüentemente, é muito útil pensar e analisar os problemas em outra direção.
4. Analise cuidadosamente o fenômeno e o fluxo do código
É importante ter cuidado quando ocorrem muitos erros. Devemos tratar cada problema com cuidado e, em seguida, analisar o fluxo do código com seriedade. Muitos problemas podem ser complicações e todos os problemas podem ser resolvidos resolvendo o problema de origem. Somente por meio de vários problemas, rastreie gradualmente a fonte, lentamente encontre a maior fonte e, em seguida, resolva a partir da fonte.
Então, esses quatro pontos, mais os métodos anteriores de coleta e investigação de problemas, devem ser uma solução muito eficiente. Parece simples, mas não é simples. Cada etapa requer muita prática e experiência e habilidades suficientes acumuladas na prática de longo prazo podem resolver rapidamente várias doenças intratáveis. Não há atalhos.
Se você deseja melhorar sua habilidade de programação, aprenda a linguagem C e programação C ++! Ultrapassagem em curva, um passo mais rápido!
[ Linguagem C C ++ aprendendo círculo de pinguim ], compartilhe (código-fonte, vídeo de combate real do projeto, notas do projeto, tutorial introdutório básico) dê as
boas-vindas a parceiros que mudam de carreira e aprendem programação, usam mais informações para aprender e crescer mais rápido do que você pensa!
Livros de aprendizagem de programação:
Vídeo de aprendizagem de programação:
