ICSE 2021

Embora escrever código às vezes pareça trivial, surgem problemas quando os humanos interpretam mal o que o código realmente faz. Uma das causas potenciais são os “átomos de confusão”, os menores padrões possíveis de código-fonte mal interpretado. Pesquisas anteriores investigaram o impacto dos átomos de confusão no código C. Os resultados mostram que os desenvolvedores cometem significativamente mais erros no código onde os átomos estão presentes.

Neste artigo, replicamos o trabalho de Gopstein et al. para a linguagem Java. Depois de derivar um conjunto de átomos de confusão para Java, realizamos um experimento de duas fases com 132 estudantes de ciência da computação (ou seja, desenvolvedores novatos).

Nossos resultados mostram que os participantes têm de 2,7 a 56 vezes mais probabilidade de cometer erros em trechos de código afetados por 7 dos 14 átomos de confusão estudados e, quando confrontados com ambas as versões dos trechos de código, os participantes perceberam a versão afetada pelo átomo de confusão como mais confusa e/ou menos legível em 10 dos 14 átomos de confusão estudados.

O registro em log é uma prática de desenvolvimento que desempenha um papel importante nas operações e no monitoramento de sistemas complexos. Os desenvolvedores colocam instruções de log no código-fonte e usam dados de log para entender como o sistema se comporta na produção. Infelizmente, antecipar onde registrar durante o desenvolvimento é um desafio. Estudos anteriores mostram a viabilidade de aproveitar o aprendizado de máquina para recomendar a colocação de logs, apesar do desequilíbrio de dados, uma vez que o log é uma fração da base geral de código. No entanto, permanece desconhecido como essas técnicas se aplicam a um ambiente industrial e pouco se sabe sobre o efeito de dados desequilibrados e técnicas de amostragem.

Neste artigo, estudamos o problema de posicionamento de logs na base de código da Adyen, uma empresa de pagamentos em grande escala. Analisamos 34.526 arquivos Java e 309.527 métodos que somam +2 milhões de SLOC. Medimos sistematicamente a eficácia de cinco modelos com base em métricas de código, exploramos o efeito das técnicas de amostragem, entendemos quais recursos os modelos consideram relevantes para a previsão e avaliamos se podemos explorar 388.086 métodos de 29 projetos Apache para aprender onde fazer login em um ambiente industrial.

Nosso modelo de melhor desempenho atinge 79% de exatidão balanceada, 81% de precisão e 60% de recall. Embora as técnicas de amostragem melhorem a recuperação, elas penalizam a precisão a um custo proibitivo. Experimentos com dados de código aberto produzem modelos de baixo desempenho em relação ao conjunto de testes da Adyen; no entanto, são úteis devido à sua baixa taxa de falsos positivos. Nossos scripts e ferramentas de suporte estão disponíveis para a comunidade.

Erros em condições binárias são uma fonte de erros em muitos sistemas de software. Eles acontecem quando os desenvolvedores usam, por exemplo, < or > em vez de <= or >=. Esses erros de limite são difíceis de encontrar e impõem trabalho manual e trabalhoso para desenvolvedores de software. Embora pesquisas anteriores tenham proposto soluções para identificar erros nas condições de contorno, o problema permanece em aberto.

Neste artigo, exploramos a eficácia dos modelos de aprendizagem profunda na aprendizagem e na previsão de erros em condições de contorno. Treinamos diferentes modelos em aproximadamente 1,6 milhões de exemplos com falhas em diferentes condições de contorno.

Alcançamos uma precisão de 85% e um recall de 84% em um conjunto de dados balanceado, mas números mais baixos em um conjunto de dados desequilibrado. Também realizamos testes em 41 bugs de condições de contorno do mundo real encontrados no GitHub, onde o modelo mostra apenas um desempenho modesto. Por fim, testamos o modelo em uma base de código Java em larga escala da Adyen, nosso parceiro industrial. O modelo relatou 36 métodos com bugs, mas nenhum deles foi confirmado pelos desenvolvedores.

Decidir o que constitui um único módulo, quais classes pertencem a qual módulo ou o conjunto certo de módulos para um sistema de software específico sempre foi uma tarefa desafiadora. O problema é ainda mais difícil em sistemas de software de grande escala compostos por milhares de classes e centenas de módulos. Ao longo dos anos, os pesquisadores têm proposto diferentes técnicas para apoiar os desenvolvedores na remodularização de seus sistemas de software. Em particular, a modularização de software baseada em pesquisa é um tópico de pesquisa ativo na comunidade de engenharia de software há mais de 20 anos.

Este artigo descreve nossos esforços na aplicação de abordagens de remodelularização de software baseadas em pesquisa na Adyen, uma empresa de pagamentos em grande escala. A base de código da Adyen tem mais de 5,5 milhões de linhas de código, divididas em cerca de 70 módulos diferentes. Aproveitamos o conhecimento existente na área para desenvolver nosso próprio algoritmo de pesquisa e aplicá-lo à nossa base de código.

Nossos resultados mostram que as abordagens baseadas em pesquisa escalam para grandes bases de código como a nossa. Nosso algoritmo pode encontrar soluções que melhorem a base de código de acordo com as métricas que otimizamos, e os desenvolvedores veem valor nas recomendações. Com base em nossas experiências, listamos então um conjunto de desafios e oportunidades para futuros pesquisadores, visando tornar a remodularização de software baseada em busca mais eficiente para empresas de software de grande escala.

As APIs da Web podem ter restrições de parâmetros, de modo que nem todos os parâmetros são sempre obrigatórios ou sempre opcionais. Além disso, a presença ou o valor de um parâmetro pode fazer com que outro parâmetro seja exigido, ou os parâmetros podem ter restrições sobre quais tipos de valores são válidos. Ter uma visão clara das restrições ajuda os consumidores de API a se integrarem sem a necessidade de suporte adicional e com menos falhas de integração. Utilizamos documentação existente e abordagens de análise de código para identificar restrições de parâmetros em APIs da web complexas.

Neste artigo, relatamos nosso estudo de caso de diversas APIs na Adyen, uma empresa de pagamentos em grande escala que oferece APIs Web complexas a seus clientes. Nossos resultados mostram que a abordagem baseada em documentação e código pode identificar 23% e 53% das restrições respectivamente e, quando combinadas, 68% delas. Refletimos também sobre os desafios atuais que estas abordagens enfrentam. Em particular, a ausência de informação que descreva explicitamente as restrições na documentação (na análise da documentação), e a engenharia de um analisador de código estático sólido que seja sensível ao fluxo de dados, mantenha referências de parâmetros mais longas em todo o código da API, e que seja capaz de executar simbolicamente as diversas bibliotecas e frameworks utilizados pela API (na análise estática).

Classificar turmas grandes tornou-se uma tarefa desafiadora e cara para muitas universidades. A Universidade de Tecnologia de Delft (TU Delft), localizada na Holanda, observou um grande aumento no número de estudantes nos últimos anos. Dado o grande crescimento da população estudantil, avaliar todas as submissões resulta em custos elevados.

Utilizamos autoavaliação e avaliação por pares na edição 2018-2019 de nosso curso de teste de software. Os alunos trabalharam em equipes de dois, e eles mesmos e seus colegas avaliaram três tarefas em nosso curso. Acabamos com 906 envios avaliados por nós mesmos e por pares, que comparamos com 248 envios avaliados por nossos TAs.

Neste artigo, relatamos as diferenças que observamos entre a classificação própria, dos pares e do TA. Nossas descobertas mostram que: (i) as notas próprias tendem a ser 8-10% mais altas do que as notas dos colegas, em média; (ii) as notas dos pares parecem ser um bom aproximador das notas do TA; nos casos em que a classificação própria e a dos pares diferem significativamente, a classificação do TA parece situar-se no meio, e (iii) o género e a nacionalidade do aluno não parecem afectar a classificação própria e dos pares.

Refatoração é o processo de alteração da estrutura interna do software para melhorar sua qualidade sem modificar seu comportamento externo. Antes de realizar atividades de refatoração, os desenvolvedores precisam identificar oportunidades de refatoração. Atualmente, a refatoração da identificação de oportunidades depende muito da experiência e da intuição dos desenvolvedores.

Neste artigo, investigamos a eficácia dos algoritmos de aprendizado de máquina na previsão de refatorações de software. Mais especificamente, treinamos seis algoritmos de aprendizado de máquina diferentes com um conjunto de dados que compreende mais de dois milhões de refatorações de 11.149 projetos do mundo real dos ecossistemas Apache, F-Droid e GitHub.

Os modelos resultantes prevêem 20 refatorações diferentes em níveis de classe, método e variável com uma precisão geralmente superior a 90%. Nossos resultados mostram que (i) Random Forests são os melhores modelos para prever a refatoração de software, (ii) as métricas de processo e propriedade parecem desempenhar um papel crucial na criação de melhores modelos e (iii) os modelos generalizam bem em diferentes contextos.

A Inteligência Artificial (IA) e o Aprendizado de Máquina (ML) estão difundidos no cenário atual da ciência da computação. No entanto, ainda existe uma falta de experiência em engenharia de software e de melhores práticas neste campo. Uma dessas práticas recomendadas, a análise estática de código, pode ser usada para encontrar code smells, ou seja, defeitos (potenciais) no código-fonte, oportunidades de refatoração e violações de padrões de codificação comuns.

Nossa pesquisa teve como objetivo descobrir os code smells mais comuns em projetos de ML. Reunimos um conjunto de dados de 74 projetos de ML de código aberto, instalamos suas dependências e executamos o Pylint neles. Isso resultou em um top 20 de todos os code smells detectados, por categoria. A análise manual desses code smells mostrou principalmente que a duplicação de código é generalizada e que a convenção PEP8 para estilo de nomenclatura de identificador pode nem sempre ser aplicável ao código ML devido à sua semelhança com a notação matemática. O mais interessante, porém, é que encontramos várias obstruções importantes à manutenibilidade e reprodutibilidade de projetos de ML, principalmente relacionadas ao gerenciamento de dependências de projetos Python. Também descobrimos que o Pylint não pode verificar de forma confiável o uso correto de dependências importadas, incluindo bibliotecas de ML importantes, como PyTorch.

Detectar problemas de desempenho devido a código abaixo do ideal durante o processo de desenvolvimento pode ser uma tarefa difícil, especialmente quando se trata de localizá-los após perceber a degradação do desempenho após a implantação. A análise estática tem o potencial de fornecer feedback antecipado sobre problemas de desempenho aos desenvolvedores, sem a necessidade de executar criadores de perfil com testes de desempenho caros (e muitas vezes indisponíveis).

Desenvolvemos uma ferramenta VSCode que integra os resultados da análise de desempenho estático do Infer por meio de anotações e decorações de código (revelando os resultados da análise de complexidade no contexto) e visualizações de painel lateral mostrando detalhes e visões gerais (permitindo a explicabilidade dos resultados). Além disso, projetamos nosso sistema para interatividade para permitir maior capacidade de resposta às alterações de código à medida que elas acontecem. Avaliamos a eficácia de nossa ferramenta medindo a sobrecarga que a integração da análise estática de desempenho introduz no fluxo de trabalho de desenvolvimento.

Além disso, relatamos um estudo de caso que ilustra como nosso sistema pode ser usado para raciocinar sobre o desempenho do software no contexto de um bug de desempenho real no projeto de código aberto ElasticSearch.

• Vídeo de demonstração: https://www.youtube.com/watch?v=-GqPb_YZMOs
• Repositório: https://github.com/ipa-lab/vscode-infer-performance

Os logs de software são de grande valor em projetos industriais e de código aberto. O registro de análise móvel permite que os desenvolvedores coletem registros dos usuários finais ao custo de registrar e transmitir registros pela Internet para uma infraestrutura centralizada. O objetivo deste artigo é dar o primeiro passo na caracterização das práticas de registro de uma biblioteca de registro analítico móvel amplamente adotada, nomeadamente Firebase Analytics. Com este estudo, pretendemos compreender quais são as necessidades comuns dos desenvolvedores que levam os profissionais a adotar práticas de registro em dispositivos móveis.

Propomos uma avaliação empírica do uso do Firebase Analytics em aplicativos Android de código aberto que mostra como os logs de análise móvel são menos difundidos e menos mantidos do que o código de registro tradicional. Finalmente, embora o objetivo principal do registro tradicional consista na coleta de informações para fins de depuração, o registro torna-se mais centrado no usuário quando a análise móvel é usada para registro.