6 Trabalhos relacionados
6.1 Estudos qualitativos envolvendo desenvolvedores
Greiler, Deursen e Storey (2012) realizaram uma pesquisa qualitativa, utilizando técni- cas de Grounded Theory, com o objetivo de entender como programadores e testadores atuam quando precisam testar sistemas baseados em plug-in. Os autores iniciaram a pesquisa com um estudo exploratório e em seguida conduziram uma série de entrevistas semiestruturadas. As informações levantadas nas entrevistas foram organizadas em códigos, conceitos e categorias, através da técnica de coding, do método GT. 25 integrantes da comunidade Eclipse foram entrevistados, incluindo desenvolvedores (64%), testadores (6%) e gerentes ou líderes. Assim como este trabalho, Greiler, Deursen e Storey preten-
diam entender como os profissionais da área de desenvolvimento de software agiam num determinado contexto: no caso deles testes de sistemas baseados em plug-in e no caso deste trabalho, tratamento de exceções. Dessa forma, a mesma abordagem de estudo qualitativo foi utilizada neste trabalho: entrevistas semi-estruturadas, técnicas de GT e
survey de validação. Porém enquanto os autores selecionaram participantes com diversos
perfis (desenvolvedores, testadores, gerentes de projeto, etc.) e diferentes empresas, este trabalho focou numa única instituição e apenas em profissionais exercendo a função de desenvolvedor. A expansão deste trabalho para diversas organizações está como objetivo de trabalhos futuros.
Em se tratando de pesquisas qualitativas que abordam o tema tratamento de exce- ções, existem poucos estudos qualitativos conduzidos com desenvolvedores, tendo como
precursores Shah, Gorg e Harrold que realizaram dois estudos que focam a perspectiva do desenvolvedor (2008 e 2010).
O primeiro trabalho (SHAH; GÖRG; HARROLD, 2008b) conduziu um estudo com 9 programadores para avaliar como eles lidam com o tratamento de exceções. O trabalho foi dividido em duas partes: na parte 1, os participantes responderam perguntas que explicam como eles lidam com exceções e quais abordagens utilizam ao implementar código de tratamento de exceções e na segunda parte do estudo, os participantes foram encorajados a usar a ferramenta proposta pelos autores, EnHanCe - Exception HANdling CEntric
Visualization, que tem o objetivo de prover a visualização de fluxos de tratamento de
exceções.
Os estudos mostraram que os desenvolvedores não consideram a implementação do tratamento de exceções como uma atividade de alta prioridade, muitos consideram que consome muito tempo e utilizam esse recurso em primeiro lugar para fins de debug no código. Os participantes da pesquisa também acreditam que uma implementação do código excepcional bem planejada pode ser adiada até que erros ocorram naquele código. A respeito da ferramenta de visualização, a maioria dos participantes consideraram a visão quantitativa difícil de compreender, porém avaliaram as outras duas visões como sendo de bastante utilidade, pois permitem enxergar construções não vistas antes (por exemplo blocos não alcançados) e o número de níveis que o fluxo de exceção percorre (distância entre o throw e o catch). Porém os participantes não se mostraram motivados a mudar seu modo de trabalho em relação ao tratamento de exceções. A partir desses resultados, o artigo propõe a criação de um novo papel no processo de desenvolvimento de software - o engenheiro de exceção - cuja função é fazer o design, implementar e integrar o código de tratamento de exceções.
Para aumentar o entendimento do ponto de vista dos programadores com respeito ao tratamento de exceções, Shah, Gorg e Harrold se manteram no tema e geraram outro estudo (SHAH; GORG; HARROLD, 2010) que foca na comparação entre o entendimento dos programadores com pouca experiência profissional e daqueles experientes. O trabalho anterior (SHAH; GÖRG; HARROLD, 2008b) serviu como fonte de informação para os desen-
volvedores novatos (média de 2 anos de experiência profissional) e novas entrevistas foram feitas com programadores experientes. O guia de entrevista utilizado no primeiro estudo serviu de base para o estudo dos experientes, que foi realizado com 6 desenvolvedores que tinham entre 5 e 16 anos de experiência profissional. As entrevistas semiestruturadas foram gravadas, transcritas e codificadas. Os pesquisadores perceberam que os experientes
consideram que a implementação do tratamento de exceções é uma atividade indistinguível e inseparável da implementação das funcionalidades principais do sistema (happy-path). Além disso, utilizam as exceções para exibir erros de maneira satisfatória, de forma que o usuário entenda qual o motivo do erro. Em relação ao comportamento dos desenvolvedores novatos, os experientes acreditam que os inexperientes não entendem a importância de um tratamento de exceções adequado e reconheceram comportamentos que eles mesmos reproduziam antes de ganhar experiência profissional. O trabalho conclui que, em geral, novatos negligenciam o tratamento de exceções, enquanto que os profissionais experientes consideram essa como sendo uma parte crucial do processo de desenvolvimento.
Os artigos de Shah, Gorg e Harrold (2008 e 2010) são os mais similares a esta pesquisa, pois visam entender como os programadores lidam com o código de tratamento de exceções, se utilizando também de entrevistas semiestruturadas como meio de coleta de dados. Foram encontrados, inclusive, alguns resultados semelhantes, como o uso do mecanismo de tratamento de exceção para fins de debug e o adiamento de decisões sobre o tratamento de exceções. Porém neste trabalho não chegamos a diferenciar as abordagens utilizadas por novatos e experientes, já que os respondentes possuem um perfil uniforme em relação a experiência profissional, podendo a maioria ser considerada como experiente. Neste trabalho, além de buscar entender como os programadores lidam com o tratamento de exceções, também focamos nas dificuldades que eles enfrentam ao lidar com esse código. Com isso, a ferramenta proposta por nós está alinhada a uma das maiores dificuldades relatadas, que é a falta de documentação da política. Como consequência, o objetivo da ferramenta proposta também difere da ferramenta proposta por Shah, Gorg e Harrold, podendo ser usadas de forma complementar.