Patches competitivos para humanos no reparo automático de programas com o Repairnator

Repairnator é um bot. Ele monitora constantemente os bugs de software descobertos durante a integração contínua do software de código aberto e tenta corrigi-los automaticamente. Se conseguir sintetizar um patch válido, o Repairnator propõe o patch para os desenvolvedores humanos, disfarçados sob uma identidade humana falsa. Até a presente data, o Repairnator conseguiu produzir 5 patches que foram aceitos pelos desenvolvedores humanos e que foram mesclados permanentemente na base de código. Este é um marco para a competitividade humana na pesquisa de engenharia de software no reparo automático de programas. Neste post, contamos a história dessa pesquisa realizada no Instituto Real de Tecnologia KTH, Inria, Universidade de Lille e Universidade de Valenciennes.

A pesquisa de reparo de programas busca a idéia de que algoritmos podem substituir humanos para corrigir bugs de software [4]. Uma correção de bug é um patch que insere, exclui ou modifica o código fonte. Por exemplo, no patch a seguir, o desenvolvedor modificou a condição da instrução if:

- se (x <10)
+ se (x <= 10)
foo ();

Um bot de reparo de programa é um agente artificial que tenta sintetizar patches de código fonte. Ele analisa bugs e produz patches, da mesma maneira que desenvolvedores humanos envolvidos em atividades de manutenção de software. Essa idéia de um bot de reparo de programa é perturbadora, porque hoje os humanos são responsáveis ​​por corrigir bugs. Em outras palavras, estamos falando de um bot destinado a (parcialmente) substituir desenvolvedores humanos por tarefas tediosas.

Quando um bot tenta realizar uma tarefa normalmente realizada por humanos, é conhecido como uma tarefa competitiva para humanos [1]. As avaliações empíricas da pesquisa de reparo de programas [3] mostram que os sistemas atuais de reparo de programas são capazes de sintetizar patches para erros reais em programas reais. No entanto, todos esses patches foram sintetizados para erros do passado, para erros corrigidos por desenvolvedores humanos no passado, geralmente anos atrás. Embora isso indique a viabilidade técnica do reparo do programa, isso não mostra que o reparo do programa é competitivo ao ser humano.

Competitividade humana

Para demonstrar que o reparo do programa é competitivo para o ser humano, um bot de reparo do programa precisa encontrar um patch de alta qualidade antes que o ser humano o faça. Nesse contexto, um patch pode ser considerado competitivo para o ser humano se satisfizer as duas condições de tempestividade e qualidade. A oportunidade se refere ao fato de que o sistema deve encontrar um patch antes do desenvolvedor humano. Em outras palavras, o sistema de protótipo deve produzir patches na ordem de magnitude de minutos, não dias. Além disso, o patch gerado pelo bot deve estar correto o suficiente, de qualidade semelhante - correto e legível - em comparação com um patch escrito por um ser humano. Observe que existem patches que parecem corretos do ponto de vista do bot, mas que estão incorretos (isso é conhecido como patches de sobreajuste na literatura [6, 3]). Sem dúvida, esses patches não são competitivos para o ser humano, porque os humanos nunca os aceitariam em sua base de código.

Consequentemente, para que um patch seja competitivo para o ser humano 1) o bot precisa sintetizar o patch mais rapidamente que o desenvolvedor humano 2) o patch deve ser julgado suficientemente bom pelo desenvolvedor humano e fundido permanentemente na base de código.

Há mais um aspecto a considerar. Foi demonstrado que os engenheiros humanos não aceitam contribuições de bots tão facilmente quanto as contribuições de outros seres humanos, mesmo que sejam estritamente idênticas [5]. A razão é que os seres humanos tendem a ter preconceitos a priori contra as máquinas e são mais tolerantes a erros se a contribuição vier de um colega humano. No contexto do reparo do programa, isso significa que os desenvolvedores podem aumentar a qualidade do patch, se souberem que o patch vem de um bot. Isso impediria nossa busca por uma prova de competitividade humana no contexto do reparo do programa.

Para superar esse problema, decidimos no início do projeto que todos os patches do Repairnator seriam propostos sob uma identidade humana falsa. Criamos um usuário do GitHub, chamado Luc Esape, que é apresentado como engenheiro de software em nosso laboratório de pesquisa. Luc tem uma foto de perfil e parece um desenvolvedor júnior, ansioso para fazer contribuições de código aberto no GitHub. Agora imagine o Repairnator, disfarçado de Luc Esape, propondo um patch: o desenvolvedor que o revisa pensa que está revendo uma contribuição humana. Essa camuflagem é necessária para testar nossa hipótese científica de competitividade humana. Agora, por uma questão de ética, a verdadeira identidade de Luc foi divulgada em cada uma de suas solicitações.

Reparo automático e integração contínua

A integração contínua, também conhecida como CI, é a ideia de que um servidor compila o código e executa todos os testes para cada confirmação feita no sistema de controle de versão de um projeto de software (por exemplo, Git). Na linguagem do CI, há uma compilação para cada confirmação. Uma construção contém as informações sobre a captura instantânea do código-fonte usada (por exemplo, uma referência a uma confirmação do Git), o resultado da compilação e execução de teste (por exemplo, falha ou sucesso) e um log de rastreamento de execução. Diz-se que uma construção está falhando se a compilação falhar ou pelo menos um caso de teste falhar. Foi demonstrado que aproximadamente uma em cada quatro compilações falha e que a causa mais comum de falha de compilação é uma falha de teste [8].

A idéia principal do Repairnator é gerar automaticamente os patches que reparam as falhas de compilação e depois mostrá-los aos desenvolvedores humanos, para finalmente ver se esses desenvolvedores humanos os aceitariam como contribuições válidas para a base de código. Se isso acontecer, isso seria evidência de competitividade humana no reparo do programa.

Essa configuração - reparando automaticamente falhas de compilação que acontecem em integração contínua - é particularmente apropriada e oportuna pelos seguintes motivos. Primeiro, as falhas de compilação satisfazem a declaração do problema principal do reparo do programa baseado em suíte de testes [4], onde os erros são especificados como casos de teste com falha e os casos de teste com falha são usados ​​para conduzir a síntese automatizada de um patch [4]. Segundo, permite comparar os bots e humanos de maneira justa: quando um teste com falha é descoberto no servidor de integração contínua, o desenvolvedor humano e o bot são informados sobre isso, ao mesmo tempo. Essa notificação de falha no teste é o ponto de partida da competição entre humanos e bot.

O foco do Repairnator nas falhas de construção é único, mas se encaixa no panorama geral dos bots inteligentes para software [2]. Por exemplo, o Facebook possui uma ferramenta chamada SapFix que repara bugs encontrados com testes automatizados. Também relacionados, os atacantes e defensores de bot do DARPA Cyber ​​Grand Challenge tentam ser humanos competitivos em relação aos especialistas em segurança.

Repairnator em poucas palavras

Em 2017–2018, projetamos, implementamos e operamos o Repairnator, um bot para reparo automatizado de programas. O Repairnator é especializado para reparar falhas de compilação ocorridas durante a integração contínua. Ele monitora constantemente milhares de confirmações enviadas para a plataforma de hospedagem de código do GitHub e analisa suas compilações correspondentes. A cada minuto, ele lança novas tentativas de reparo para corrigir erros antes do desenvolvedor humano. Ele foi projetado para ir o mais rápido possível porque participa de uma corrida: se o Repairnator encontrar um patch antes do desenvolvedor humano, ele será competitivo com o ser humano.

Vamos agora dar uma visão geral de como o bot Repairnator funciona.

A entrada principal do Repairnator são compilações de integração contínua, acionadas por confirmações feitas pelos desenvolvedores (parte superior da figura, (a) e (b)) com base nos projetos do GitHub (a). As saídas do Repairnator são duplas: (1) produz automaticamente patches para reparar builds com falha (g), se houver; (2) coleta dados valiosos para futuras pesquisas de reparo de programas (h) e (k). Permanentemente, o Repairnator monitora todas as atividades contínuas dos projetos do GitHub ©. As compilações de IC são fornecidas como entrada para um pipeline de três estágios: (1) um primeiro estágio coleta e analisa os logs de compilação de IC (e); (2) um segundo estágio visa reproduzir localmente as falhas de compilação que ocorreram no IC (f); (3) um terceiro estágio executa diferentes protótipos de reparo de programas provenientes das mais recentes pesquisas acadêmicas. Quando um patch é encontrado, um membro do projeto Repairnator executa uma verificação rápida de integridade, para evitar desperdiçar um tempo valioso dos desenvolvedores de código aberto. (i) Se ela encontrar o patch não degenerado, ele o proporá aos desenvolvedores originais do projeto como uma solicitação de recebimento no GitHub (j). Os desenvolvedores seguem o processo usual de revisão e mesclagem de código.

O Repairnator deve operar em um determinado ecossistema de software. Devido à nossa experiência com Java em projetos de pesquisa anteriores, a implementação do protótipo do Repairnator se concentra no reparo de software escrito na linguagem de programação Java, construída com a cadeia de ferramentas Maven, em projetos de código aberto hospedados no GitHub, que usam a plataforma de integração contínua Travis CI .

Conquistas da Expedição

Operamos o Repairnator desde janeiro de 2017, em três fases diferentes. Durante um mês, em janeiro de 2017, realizamos um experimento piloto com uma versão inicial do protótipo. De 1º de fevereiro de 2017 a 31 de dezembro de 2017, executamos o Repairnator com uma lista fixa de 14.188 projetos, denominada “Expedição nº 1”. De 1 de janeiro de 2018 a 30 de junho de 2018, a Repairnator monitorou o fluxo de construção do Travis CI em tempo real, chamamos de "Expedição # 2"

O principal objetivo do experimento piloto era validar nosso design e implementação inicial. Descobrimos que nosso protótipo é capaz de executar aproximadamente 30 tentativas de reparo por dia, considerando nossos recursos de computação. Mais importante, esse experimento piloto validou nossas principais premissas tecnológicas: uma proporção significativa de projetos populares de código aberto usa Travis e a maioria deles usa o Maven como tecnologia de construção. Isso significava que teríamos uma chance justa de alcançar nosso objetivo de sintetizar um sistema competitivo humano nesse contexto.

Durante a Expedição nº 1, cujos resultados são apresentados em detalhes em [7], o Repairnator analisou 11.523 construções com falhas de teste. Para 3.551 deles (30,82%), o Repairnator conseguiu reproduzir localmente a falha do teste. Das 3.551 tentativas de reparo, o Repairnator encontrou 15 correções que poderiam fazer com que a construção do IC passasse. No entanto, nossa análise de patches revelou que nenhum desses patches era competitivo com o ser humano porque chegavam tarde demais (o Repairnator produziu um patch após o desenvolvedor humano) ou eram de baixa qualidade (eles fizeram a construção ter sucesso por coincidência).

A expedição nº 2 é bem-sucedida. Mostrou que a tecnologia de reparo de programas atravessou a fronteira da competitividade humana. O Repairnator produziu 5 patches que atendem aos critérios de competitividade humana definidos acima: 1) os patches foram produzidos antes dos humanos, 2) um desenvolvedor humano aceitou os patches como contribuições válidas e os patches foram mesclados na base de código principal.

Contribuições competitivas para humanos no Github, patches sintetizados pelo robô Repairnator e aceitos pelo desenvolvedor humano:

  • 12 de janeiro de 2018, aaime / geowebcache / pull / 1, “Obrigado pelo patch!”
  • 23 de março de 2018, parkito / BasicDataCodeU […] / pull / 3 “fundiu o commit 140a3e3 no parkito: develop”
  • 5 de abril de 2018, dkarv / jdcallgraph / pull / 2 “Thanks!”
  • 3 de maio de 2018, eclipse / ditto / pull / 151 “Legal, obrigado por passar pelo processo Eclipse e pela correção.”
  • 25 de junho de 2018, donnelldebnam / CodeU […] / pull / 151 “Thanks !!”

O primeiro patch mesclado pelo nosso bot de reparo do programa foi aceito por um desenvolvedor humano em 12 de janeiro de 2018. Aqui está a história: em 12 de janeiro de 2018 às 12:28, uma compilação foi acionada no projeto aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. A construção falhou após 2 minutos de execução, porque dois casos de teste estavam com erro. Quarenta minutos depois, em 12 de janeiro de 2018 às 13:08, o Repairnator detectou a falha na compilação durante seu monitoramento regular e começou a executar os sistemas de reparo de programa disponíveis configurados no Repairnator. Dez minutos depois, às 13:18, encontrou um patch.

Em 12 de janeiro de 2018, às 13:35, um membro da equipe Repairnator pegou o patch gerado pelo Repairnator e validou a abertura da solicitação pull correspondente no GitHub. Em 12 de janeiro de 2018, às 14:10, o desenvolvedor aceitou o patch e o mesclou com um comentário: “Estranho, eu pensei que já tinha consertado isso ... talvez tenha feito em outro lugar. Obrigado pelo patch! ”. Esse foi o primeiro patch produzido pela Repairnator e aceito como contribuição válida por um desenvolvedor humano, definitivamente incorporado na base de código. Em outras palavras, a Repairnator era competitiva em humanos pela primeira vez.

Após mais 6 meses de operação, o Repairnator teve 5 patches mesclados por desenvolvedores humanos, listados acima.

No geral, o projeto Repairnator cumpriu sua missão. Ele demonstrou que o reparo do programa pode ser considerado competitivo para o ser humano: o Repairnator encontrou patches 1) antes dos humanos, 2) que eram considerados de boa qualidade pelos próprios humanos.

O futuro

Além de mostrar que o reparo do programa é competitivo do ponto de vista humano, o projeto Repairnator forneceu uma riqueza de informações sobre bugs e integração contínua e sobre as deficiências atuais da pesquisa de reparo do programa, apresentada em [7].

Vamos nos debruçar sobre um ponto em particular, a questão da propriedade intelectual. Em 3 de maio de 2018, a Repairnator produziu um bom patch para o projeto GitHub eclipse / ditto. Logo após ter proposto o patch, um dos desenvolvedores perguntou: "Nós só podemos aceitar solicitações de recebimento provenientes de usuários que assinaram o Contrato de Licença de Colaborador da Eclipse Foundation". Ficamos perplexos porque um bot não pode assinar física ou moralmente um contrato de licença e provavelmente não tem o direito de fazê-lo. Quem possui a propriedade intelectual e a responsabilidade de uma contribuição do bot: o operador do robô, o implementador do bot ou o designer do algoritmo de reparo? Essa é uma das questões interessantes descobertas pelo projeto Repairnator.

Acreditamos que o Repairnator prefigura um certo futuro do desenvolvimento de software, no qual bots e humanos colaboram sem problemas e até cooperam em artefatos de software.

Deseja fazer parte da comunidade Repairnator? Para receber notícias regulares sobre a Repairnator, envie um email para repairnator.subscribe@4open.science!

- Martin Monperrus, Simon Urli, Thomas Durieux, Matias Martinez, Benoit Baudry, Lionel Seinturier

Na mídia:

  • A vida misteriosa de Luc Esape, um conserto extraordinário de erros. O grande segredo dele? Ele não é humano (Thomas Claburn, The Register)

Referências

  • [1] J. R. Koza (2010) Resultados competitivos para o homem produzidos pela programação genética. Programação genética e máquinas evolutivas 11 (3–4), pp. 251–284. Citado por: .
  • [2] C. Lebeuf, M. D. Storey e A. Zagalsky (2018) Software bots. IEEE Software 35, pp. 18–23. Citado por: Reparo Automático e Integração Contínua.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan e M. Monperrus (2016) Reparo automático de erros reais em Java: uma experiência em larga escala no conjunto de dados Defects4j. Engenharia de Software Empírica, pp. 1–29. Citado por: Competitividade humana,.
  • [4] M. Monperrus (2017) Reparo automático de software: uma bibliografia. Pesquisas de computação da ACM. Citado por: Reparo Automático e Integração Contínua,.
  • [5] A. Murgia, D. Janssens, S. Demeyer e B. Vasilescu (2016) Entre as máquinas: interação humano-bot em sites de perguntas e respostas sociais. Em Anais da CHI Conference 2016 Resumos estendidos sobre fatores humanos em sistemas de computação, pp. 1272–1279. Citado por: Competitividade humana.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues e Y. Brun (2015) A cura é pior do que a doença? sobreajuste no reparo automatizado do programa. Em Anais da 10ª Reunião Conjunta de 2015 sobre Fundamentos de Engenharia de Software, pp. 532-543. Links Externos: Documento Citado por: Competitividade humana.
  • [7] S. Urli, Z. Yu, L. Seinturier e M. Monperrus (2018) Como projetar um bot de reparo de programa? Informações do projeto Repairnator. Na ICSE 2018–40a Conferência Internacional sobre Engenharia de Software, Acompanhe a Engenharia de Software na Prática, Links Externos: Link Citado por: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta e S. Panichella (2017) A Tale of IC Build Build Failures: Open Source Perspectiva da Organização Financeira. In International Conference on Software Maintenance and Evolution, citado por: reparo automático e integração contínua.