Software é uma coisa muito complicada. E é um bocado curioso como as coisas podem funcionar mesmo que os registros digam o contrário
Tipo essa stacktrace aí.
Depurar erro é uma coisa comum para um analista. Na verdade, analistas passam mais tempo depurando erros do que qualquer outra coisa. O principal objetivo é achar causas raiz, só que conforme os softwares ficam cada vez maior, essas coisas ficam cada vez mais complicadas de achar. E o que é mais incrível, as coisas funcionam mesmo com erros. Na verdade elas foram desenhadas para funcionar apesar dos erros.
Como é que isso funciona? Como é que um software pode funcinar mesmo com um monte de erro pipocando nos registros? Como funciona com 55 stacktraces lá nos logs do diabo da aplicação? Essa é fácil de explicar. As aplicações são desenvolvidas majoritariamente em blocos independentes, então muitas vezes um erro em alguma das funções da aplicação não impacta naquela que você realmente precisa.
E outra coisa. As aplicações hoje em dia possuem essa propriedade com a justificativa de que a aplicação não pode parar mesmo que um erro aconteça. Sejamos sinceros, uma aplicação boa tem de ser blindada contra erros de dado, que podem ser mera ingenuidade até tentativas ação maliciosas.
É verdade. Dependendo do tipo da aplicação, a aplicação não pode parar. A aplicação de um avião certamente não pode parar no meio da atuação, caso contrário o avião cai lá embaixo e morre todo mundo.
Legal, e o que o analista faz é ficar vendo logs e descobrindo essas coisas. Isso gera duas necessidades básicas no analista:
- Saber ler
- Saber buscar texto
Conforme você acha os erros você vai lendo o que está acontecendo para tentar descobrir o que fazer para solucioná-los, mas agora vem um ponto importante.
Se a aplicação já está rodando sem problema o ideal é que você leia os registros do final pro início, mas se as coisas não estão funcionando você TEM que ler do início pro fim. Isso porque o computador tem uma propriedade muito peculiar. Por mais que você threads e processamento paralelo. A propagação de um erro é sempre sequencial. A chance de você solucionar todos os erros subsequentes ao solucionar o primeira é particularmente grande.
Então é isso, á falei bastante sobre depuração de erro para analistas. No próximo artigo eu irei cobrir isso de uma forma mais técnica.
Fuiz!
Imagens:
https://blog.jetbrains.com/idea/2010/03/groovy-stacktrace-folding/
Tipo essa stacktrace aí.
Depurar erro é uma coisa comum para um analista. Na verdade, analistas passam mais tempo depurando erros do que qualquer outra coisa. O principal objetivo é achar causas raiz, só que conforme os softwares ficam cada vez maior, essas coisas ficam cada vez mais complicadas de achar. E o que é mais incrível, as coisas funcionam mesmo com erros. Na verdade elas foram desenhadas para funcionar apesar dos erros.
Como é que isso funciona? Como é que um software pode funcinar mesmo com um monte de erro pipocando nos registros? Como funciona com 55 stacktraces lá nos logs do diabo da aplicação? Essa é fácil de explicar. As aplicações são desenvolvidas majoritariamente em blocos independentes, então muitas vezes um erro em alguma das funções da aplicação não impacta naquela que você realmente precisa.
E outra coisa. As aplicações hoje em dia possuem essa propriedade com a justificativa de que a aplicação não pode parar mesmo que um erro aconteça. Sejamos sinceros, uma aplicação boa tem de ser blindada contra erros de dado, que podem ser mera ingenuidade até tentativas ação maliciosas.
É verdade. Dependendo do tipo da aplicação, a aplicação não pode parar. A aplicação de um avião certamente não pode parar no meio da atuação, caso contrário o avião cai lá embaixo e morre todo mundo.
Legal, e o que o analista faz é ficar vendo logs e descobrindo essas coisas. Isso gera duas necessidades básicas no analista:
- Saber ler
- Saber buscar texto
Conforme você acha os erros você vai lendo o que está acontecendo para tentar descobrir o que fazer para solucioná-los, mas agora vem um ponto importante.
Se a aplicação já está rodando sem problema o ideal é que você leia os registros do final pro início, mas se as coisas não estão funcionando você TEM que ler do início pro fim. Isso porque o computador tem uma propriedade muito peculiar. Por mais que você threads e processamento paralelo. A propagação de um erro é sempre sequencial. A chance de você solucionar todos os erros subsequentes ao solucionar o primeira é particularmente grande.
Então é isso, á falei bastante sobre depuração de erro para analistas. No próximo artigo eu irei cobrir isso de uma forma mais técnica.
Fuiz!
Imagens:
https://blog.jetbrains.com/idea/2010/03/groovy-stacktrace-folding/
Nenhum comentário:
Postar um comentário