Survey de Avaliação

Após a análise das falhas apresentadas nas seções anteriores, aplicamos um questionário apenas com programadores da organização, com o objetivo de investigar como a ferramenta de crash report era utilizada. Não foi necessário realizar seleção de amostragem dos participantes, pois o objetivo do survey não dependia de nenhuma característica específica dos envolvidos. Então, enviamos o questionário para todos os programadores disponíveis de 3 equipes de desenvolvimento, atingindo em torno de 25 participantes, e obtivemos 14 respondentes.

Nosso objetivo foi apenas um: entender como os desenvolvedores utilizam informações de crashes durante o desenvolvimento. Para atingir este objetivo, foram elaboradas 5 questões mostradas na Tabela 6. Utilizamos o termo “Kibana” para representar o crash

report, pois é o termo mais conhecido pelos participantes.

# Questão

1 Você costuma utilizar o Kibana quando vai resolver alguma tarefa de correção de erro?

2 Você utiliza o Kibana para outro propósito que não seja buscar informações para corrigir algum erro?

3 Caso a resposta anterior seja positiva, para que atividades você utiliza o Kibana? 4 Suponha que você encontrou um erro no seu ambiente local e quer saber se ele ocorreu alguma vez no ambiente de produção. Você teria facilidade em utilizar o kibana para localizá-lo?

5 Você costuma monitorar no Kibana os erros dos módulos que você trabalha e corrigir proativamente ou aguarda as tarefas chegarem para você?

6 Você gostaria de compartilhar alguma ideia ou sugestão relacionada ao uso do Kibana no seu dia a dia de trabalho?

Tabela 6: Perguntas do questionário aplicado entre os programadores.

Para a primeira questão, dos 14 respondentes, 9 (64,3%) utilizam o relatório para auxiliar na correção de defeitos contra 5 (35,7%) que não utilizam. Da segunda questão obtivemos que dos 14 participantes, apenas 5 o utiliza para outros propósitos.

A terceira questão foi uma questão discursiva que servia como complemento da segunda. Ao perguntarmos quais os outros propósitos que eles utilizavam as informações do crash, dos 5 que responderam “Sim” na segunda questão, 4 afirmaram utilizar para auditoria de sistema (ou seja, rastrear os passos da execução do sistema por parte de algum usuário). O outro participante afirmou utilizá-lo no dia a dia para consultar erros “em tempo real”.

em que ele consegue consultar informações no crash report. Sete participantes responderam entre 2 e 5 e acreditamos que estes sentem alguma dificuldade em utilizar o relatório. Outros seis concentraram suas respostas entre os valores 7 e 10. Estes provavelmente utilizam o crash report sem maiores dificuldades.

A quinta questão procurou saber se os participantes utilizam o crash reporter para monitorar falhas dos módulos em que programam. Os 14 participantes responderam e apenas 1 deles respondeu que “Sim, costumo monitorar”.

Por fim, a questão 6 era de uma resposta de texto livre para sugestões para melhoria do relatório no dia a dia do programador. Um participante solicitou que dados da request fossem inclusos no relatório, para facilitar na depuração. Outro afirmou que a ferramenta não é encorajada pelos gerentes a ser utilizada e sua interface é confusa. Por fim, um dos participantes sugeriu incluir o Kibana no fluxo de correção de erros, na IDE de desenvolvimento e no sistema interno de gerenciamento de tarefas.

O survey foi suficiente para atender nossa meta. Observamos dos 14 participantes, 5 nunca utilizaram o crash report e os dados de falhas são utilizados basicamente para depuração e auditoria. É provável que a auditoria realizada esteja relacionada à identificação dos passos realizados por um usuário a fim de simular alguma falha gerada por ele. Neste caso, a auditoria torna-se também uma atividade de depuração de falhas. Vimos também que dos 14 participantes, 7 sentem dificuldades na utilização das funcionalidades do relatório de falhas e apenas 1 utiliza o relatório no dia a dia para monitoramento de erros.

3.9

Discussão

Neste capítulo apresentamos os dados coletados de uma análise manual feita em cima de falhas reais que ocorreram no período de Junho de 2018, no sistema SIPAC. Primeiramente levantamos os principais tipos de exceções lançadas no momento dos crashes e, conforme já esperado, o NullPointerException continua sendo a principal causa de falhas neste sistema. A partir dos principais tipos, selecionamos subconjuntos das falhas dos primeiros cinco tipos e realizamos uma análise mais detalhada. Selecionamos um total de 39 falhas dos diferentes tipos a fim de encontrar padrões de bugs e estudar a natureza de cada tipo de exceção.

O objetivo central desta análise foi levantar quaisquer informações de falhas ocorridas com o propósito de levá-las aos desenvolvedores, a fim de evitar novos defeitos semelhantes aos do passado. Conseguimos documentar algumas das causas e, a partir delas, tentamos

definir alguns bug patterns. Tentamos considerar como padrão de erros apenas aqueles que se repetissem (pelo menos 3 vezes) no código-fonte. Porém, devido à pouca quantidade de defeitos analisados e a especificidade de cada um, encontramos apenas 4 possíveis padrões.

Alguns dos padrões levantados poderiam ser detectados mais facilmente durante testes manuais como, por exemplo, a ausência de um método get/set de uma propriedade referenciada na JSP. Porém, nem sempre os testes cobrem todos os cenários e podemos concluir isto devido às falhas analisadas nesta pesquisa, que ocorreram de fato.

Investigamos duas ferramentas de análise estática de código, a SonarLint e a SpotBugs, ambas em sua versão de plug-in do Eclipse. Com base apenas na documentação de cada ferramenta identificamos que a maioria dos defeitos não seriam detectados. Para outros casos, foi preciso executar as ferramentas sob algumas classes específicas e também não foi reportado nenhum alerta relacionado às falhas documentadas.

Por fim, enviamos um questionário a um grupo de 25 programadores e 14 deles o responderam. Entendemos que o relatório de falha está sendo utilizado principalmente para depuração. Este resultado, juntamente com o estudo das ferramentas existentes, motivaram a proposta de implementação da CrashAwareDev, que será explicada no próximo capítulo.

4

CrashAwareDev

Com base no estudo apresentado no capítulo anterior, implementamos uma ferramenta – chamada CrashAwareDev – de apoio aos desenvolvedores de software. A CrashAwareDev foi desenvolvida em forma de plug-in do ambiente de desenvolvimento Eclipse. Ela tem como principais objetivos (i) aproximar o programador ao crash report, apresentando informações do relatório diretamente na IDE e (ii) a prevenção de falhas, através de uma análise estática de código realizada em tempo de codificação.

Algumas ferramentas de análise estática, discutidas na seção 3.7, por serem de código aberto, poderiam ser estendidas para adicionar novas regras de recomendação1. Porém, elas propõem busca por padrões de várias categorias como segurança, desempenho, etc, e o foco de nosso trabalho foi apenas em cima de padrões que podem ocasionar uma falha de sistema (i.e, através de uncaught exceptions). Além disso, necessitávamos ainda criar novas

views no Eclipse além dos alertas de recomendação. Por estes motivos e pela facilidade de

customização, optamos por estender a ExceptionPolicyExpert, proposta por Montenegro (MONTENEGRO, 2017). Utilizamos a funcionalidade de recomendação implementada na ExceptionPolicyExpert e fizemos as adaptações necessárias para análise de potenciais bugs no código-fonte. Além disso, adicionamos funcionalidades que se comunicam diretamente com o servidor do Elasticsearch (utilizado pelo relatório de falhas do SIPAC) para trazer informações de crashes durante a tarefa de desenvolvimento.

Nas próximas seções mostraremos os detalhes da implementação e funcionalidades da CrashAwareDev. A seção 4.1 descreve uma visão geral do plug-in, mostrando sua interface e funcionalidades. Em seguida, na seção 4.2, apresentaremos sua arquitetura e os detalhes de sua implementação. Por fim, na seção 4.3, discutiremos os principais pontos apresentados no capítulo.

1_{Ferramentas de recomendação emitem alertas sobre potenciais problemas no código-fonte analisado,} orientando o programador durante o desenvolvimento