A Multidimensional Empirical
Study on Refactoring Activity
Nikolaos Tsantalis, Victor Guana, Eleni Stroulia, Abram Hindle Department of Computer Science and Software Engineering
Concordia University, Montreal, Quebec, Canada Department of Computing Science
Introdução
• Apresenta um estudo empírico sobre a
atividade de refatoração em três projetos bem conhecidos.
• Responde cinco questões de pesquisa que exploram os diferentes tipos de refatorações aplicadas a projetos.
Introdução
• O estudo se concentra principalmente em refatorações de:
• Alto nível - são alterações que mudam as • Alto nível - são alterações que mudam as
assinaturas de classes, métodos e campos.
• Médio nível - são alteração que mudam
blocos de código (por exemplo, Extract Method)
Projetos analisados
• Seleção dos Repositórios:
– JUnit – Framework de testes com mais de 12 anos de desenvolvimento e 1.018 revisões analisadas.
– Jakarta HTTPCore – Conjunto de componentes Java utilizados para implementar serviços baseados em HTTP do cliente e do lado do servidor. 7 anos de desenvolvimento e 1.588 revisões analisadas.
e 1.588 revisões analisadas.
– Jakarta HTTPClient – fornece aplicações do lado do cliente com autenticação e gerenciamento de conexão. 06 anos de desenvolvimento e 1.838 revisões analisadas.
• Justificativa:
– JUnit por ser bem estudado na literatura.
– Os dois componentes HTTP Jacarta por serem geridos pela mesma equipe . A comparação da análise histórica permitirá investigar se os tipos de refatorações aplicadas dependem da equipe de desenvolvimento, ou se eles são ditadas pelas necessidades específicas do projeto..
SVN, GIT e comparação de versões
• Repositório centralizado implica em histórico linear (quase um sistema de bkp)
SVN, GIT e comparação de versões
• O Git – desenvolvido para atender às
demandas de controle de versão do kernel do sistema operacional Linux.
– O desenvolvimento do Linux por sua própria natureza necessitava de um modelo distribuído de versionamento, onde commits encontram-se espalhados em inúmeras linhas de desenvolvimento paralelas (branches) e devem passar por um processo de aprovação.
SVN, GIT e comparação de versões
• Repositório distribuído e descentralizado, grafo acíclico dirigido.
– Comp(C1,C2) = 0 – Comp(C1,C3) = 0 – Comp(C2,C4) = X
– Comp(C3, C5), onde C5 = C4 U C3 (fusão de commits) encontrará X novamente.
• Obs.: uma das aplicações do grafo dirigido sem ciclo em informatica é a estrutura de diretório num típico sistema de arquivos UNIX.
RQ1: Os desenvolvedores de software aplicam diferentes tipos de operações de refatoração no
código de teste e de produção?
• Junit : 383 refatorações detectadas
– 219 (57%) código produção – 164 (43%) código de teste
• HTTPCore : 527 refatorações detectadas
– 421 (80%) código produção – 106 (20%) código de teste
• HTTPClient : 198 refatorações detectadas
– 161 (81%) código produção – 37 (19%) código de teste
RQ1: Os desenvolvedores de software aplicam diferentes tipos de operações de refatoração no
RQ1: Os desenvolvedores de software aplicam diferentes tipos de operações de refatoração no
código de teste e de produção? - Conclusão
• Conclui-se que há uma maior variedade de tipos de refatoração aplicadas ao código de produção. Foco: Melhoria no projeto (retirar code smells e promover a Melhoria no projeto (retirar code smells e promover a modularização)
• Em termos de refatorações observados no código de teste, há um foco claro na reorganização interna das classes de cada projeto em pacotes e rename de classes por razões conceituais.
RQ2: Quais desenvolvedores são Responsáveis por refatorações?
- JUnit referencia 32 desenvolvedores.
- Os dois maiores contribuintes: David Saff (63% dos commits) e Kent Beck (12% dos commits)
RQ2: Quais desenvolvedores são Responsáveis por refatorações?
- HTTPCore: 08 Desenvolvedores. Os dois maiores contribuintes: Oleg Kalnichevski (78% dos commits) e Roland Weber (8% dos commits)
RQ2: Quais desenvolvedores são
Responsáveis por refatorações?
- HTTPClient: 09 Desenvolvedores. Os dois maiores contribuintes: Oleg Kalnichevski (58% dos commits) e Jonathan Moore (4º lugar com 6% de commits).
- Sebastian Bazley e Roland Weber (o segundo e terceiro lugar na lista dos committers com 18% e 16% do total de commits, lista dos committers com 18% e 16% do total de commits, respectivamente) não contribuíram com refatorações no projeto HTTPClient.
RQ2: Quais desenvolvedores são
Responsáveis por refatorações?
-Conclusão
• Observou-se que desenvolvedores específicos assumiram a responsabilidade de planejamento e realização de refatorações.
refatorações.
• Nos projetos estudados esse papel foi cumprido, principalmente por um único desenvolvedor atuando como gerente de refatoração.
RQ3: Há mais atividade de refatoração antes do lançamento de versão que depois?
• Inspecionamos a atividade de refatoração em torno dos pontos de liberação (nova versão) ao longo do tempo de vida dos três projetos em estudo.
• Definição de janelas de 80 dias em torno de cada data de lançamento. Cada janela foi dividida em dois grupos de 40 dias, a fim de dividir a análise nos períodos antes e depois de um ponto de lançamento
RQ3: Há mais atividade de refatoração antes do lançamento de versão que depois?
RQ3: Há mais atividade de refatoração antes do lançamento de versão que depois?
RQ3: Há mais atividade de refatoração antes do lançamento de versão que depois?
RQ3: Há mais atividade de refatoração antes do lançamento de versão que depois? - Conclusão
• Nos nossos três estudos de caso, observou-se que a atividade de refatoração é significativamente mais freqüente antes de um lançamento que depois.
• Acreditamos que essa atividade é motivada pelo desejo de:
– melhorar o design do projeto, e
– preparar o código para futuras extensões antes de versões estáveis da API serem liberadas para o público.
RQ4: Atividade de refatoração no código de produção precedido pela adição ou modificação
de código de teste?
Metodologia para estudar esta questão envolveu três etapas:
(i) A detecção de atividade de teste,
(ii) a inspeção manual de hotspots de teste, e (ii) a inspeção manual de hotspots de teste, e
(iii) construção análise janela (último dia de cada período de teste)
O pivô da janela (ponto zero) é rotulado como Fim do período de testes (ETP).
RQ4: Atividade de refatoração no código de produção precedido pela adição ou modificação
de código de teste? jUnit
RQ4: Atividade de refatoração no código de produção precedido pela adição ou modificação
de código de teste? HTTPCore
RQ4: Atividade de refatoração no código de produção precedido pela adição ou modificação
de código de teste? HTTPClient
RQ4: Atividade de refatoração no código de produção precedido pela adição ou modificação
de código de teste? - Conclusão
• Encontraram atividade refatoração intensa durante os períodos de teste dos projetos que diminuiu imediatamente após o término do período de testes.
período de testes.
• Resultados e posterior inspeção manual levaram a concluir que os testes e refatoração são dependentes implicando as adoção de práticas de desenvolvimento orientado a testes nos projetos analisados.
RQ5: Qual é o objetivo das refatorações aplicadas?
• O processo foi realizado em duas fases:
• 1ª fase, um subconjunto de refatorações selecionados aleatoriamente foi examinada (o código fonte antes e depois da aplicação da refatoração com uma ferramenta de comparação de texto - diff). Em seguida, definiram regras para classificar uma instância de refatoração em cada uma das categorias definidas nesta fase.
em cada uma das categorias definidas nesta fase.
• 2ª fase, realizaram uma rotulagem sistemática das instâncias de refatoração usando o mesmo método de inspeção por aplicação das regras acima mencionadas. Para cada instância de refatoração, os autores inspecionou o relatório diff, bem como os registros de commit correspondentes e sugeriam um rótulo. No caso de desacordo, uma discussão com argumentos de ambos os lados tomaram lugar, a fim de chegar a um consenso
RQ5: Qual é o objetivo das refatorações aplicadas?
• A inspeção manual envolveu 210 Extract Method e 70 Refatorações relacionada Herança (inspeção durou aproximadamente 40 horas – 5 dias úteis ).
• O tempo de inspeção para cada refatoração foi entre 5 a 10 minutos, dependendo da complexidade do relatório diff e o número de arquivos afetados pela refatoração correspondente.
RQ5: Qual é o objetivo das refatorações aplicadas?
• A motivação para realizar Extract Method foi classificação com:
– Resolução de code smell, – Resolução de code smell, – Extensão e
RQ5: Qual é o objetivo das refatorações aplicadas?
RQ5: Qual é o objetivo das refatorações aplicadas?
Análise dos resultados de cada projeto separadamente (Extract Method):
• JUnit (onde 53% das refatorações foram aplicados para a resolução de code smells).
para a resolução de code smells).
• HTTP-Client (onde 63% dos refatoramentos foram aplicados para a resolução de code smells).
• HTTPCore (onde 74% das refatoramentos foram aplicados para fins de extensão).
RQ5: Qual é o objetivo das refatorações aplicadas?
• Refatorações relacionada Herança (Pull
Up/Push Down Method/Field, Extract
Superclasse/Interface). Foram encontradas
três motivações principais: três motivações principais:
– Resolução code Smell, – Extensão e
RQ5: Qual é o objetivo das refatorações aplicadas?
RQ5: Qual é o objetivo das refatorações aplicadas? - Conclusão
• Encontramos uma grande variedade de razões que motivam a aplicação da refatoração Extract Method:
– Code Smell (decomposição dos métodos) foi a motivação mais dominante.
dominante.
– Extensão a principal motivação foi a introdução de Factory method
• Quanto refatorações relacionadas a herança a principal motivação foi:
Ameaças à Validade do Estudo
• Validade interna: Presença de falsos negativos (ou seja, refatorações reais não detectados).
• A validade externa está ameaçada pelo escopo • A validade externa está ameaçada pelo escopo do estudo. Os projetos selecionados são desenvolvidos em Java, são gerenciados por equipes relativamente pequenas e constituem bibliotecas (no caso de componentes HTTP) ou estruturas (no caso do JUnit).
