“When and Why Your Code Starts to Smell Bad”

Tufano M., Palomba F., Bavota G., Oliveto R., Di Penta M., De Lucia A., Poshyvanyk D. [2015]

37th International Conference on Software Engineering (ICSE)

Apresentador: Carlos Eduardo Dantas

1

ROTEIRO

• Introdução.

• Objetivos.

• Metodologia.

• Ameaças à validade.

• Conclusão.

2

INTRODUÇÃO

• Débito técnico – ‘dívida’ que equipes de desenvolvimento assumem quando adotam uma metodologia mais fácil/rápida para criação de Sistemas, possivelmente comprometendo qualidade e gerando impactos em médio prazo;

• Faltam evidências empíricas sobre como, quando e por que várias formas de débitos técnicos ocorrem em Sistemas.

3

INTRODUÇÃO

• Code Smells são sintomas de um design fraco, com escolhas de implementação ruins, contribuindo diretamente para o aumento dos débitos técnicos.

• Possuem diversos impactos negativos sobre o código-fonte.

4

INTRODUÇÃO

• Impactos negativos dos Code Smells sobre o código-fonte• Code Smells dificultam a compreensão do código-fonte [Abbes et al. CSMR 2011]

5

INTRODUÇÃO

• Impactos negativos dos Code Smells sobre o código-fonte• Code Smells estão propensos a gerar mais ‘faltas’ no código-fonte, assim como o

aumento de mudanças nas classes, afetando a manutenibilidade [Khomh et al. EMSE 2012]

6

INTRODUÇÃO

• Impactos negativos dos Code Smells sobre o código-fonte• Code Smells aumentam os custos de manutenção sobre o Sistema [Banker et al.

Communications of the ACM]

7

INTRODUÇÃO

• Estudos que tentam analisar a vida útil dos Code Smells• Desenvolvedores de Sistemas estão cientes dos Code Smells, mas não estão muito

preocupados com o impacto destes [Peters and Zaidman - CSMR 2012]

8

INTRODUÇÃO

• Estudos que tentam analisar a vida útil dos Code Smells• Desenvolvedores de Sistemas adiam as operações de refactoring no código-fonte por

diversos motivos, e estes tendem a permanecer

por longos períodos de tempo

[Arcoverde et al. - IWRT 2011]

9

INTRODUÇÃO

• Algumas técnicas tem sido propostas para detectar Code Smells• Baseado em restrições sobre métricas

• Análise estática do código-fonte

• Análise de mudanças no Sistema

10

INTRODUÇÃO

• Outras propostas surgiram com sugestões para operações de refactoring

11

INTRODUÇÃO

• Estudos não tem considerado as circunstâncias que podem ter causado a introdução dos Code Smells no código-fonte;

• Não existem estudos empíricos que investigam quando e como os Code Smells são introduzidos nos Sistemas• O senso comum sugere que atividades urgentes de manutenção e pressão

sobre prazos são a causa da introdução dos Code Smells

12

OBJETIVOS

• Analisar o histórico de mudanças em um conjunto de Sistemas, investigando:• RQ1: Quando os Code Smells foram introduzidos pelos desenvolvedores;

• Quando a classe é criada? Em atividades de manutenção específicas? Gradualmente com a evolução do Software?

• RQ2: Quais circunstâncias e motivos estão por detrás do aparecimento dos Code Smells?• Desenvolvedores inexperientes? Projetos próximos do deadline? Commits específicos de

correção de bugs ou novas funcionalidades?

13

METODOLOGIA

1) Escolha de 200 projetos pertencentes a 3 ecossistemas: Android, Apache e Eclipse

14

METODOLOGIA

2) Escolha de 5 Code Smells (catálogo Fowler) para serem analisados• Blob Class: classes com grande quantidade de linhas, com diferentes

responsabilidades e que monopolizam a maior parte do processamento do Sistema.

• Class Data Should be Private: classe que expõe seus atributos, quebrando encapsulamento.

• Complex Class: classe com alta complexidade ciclomática.

• Functional Decomposition: classe que possui muitos atributos e poucos métodos, com pouca ou nenhuma utilização de herança ou polimorfismo.

• Spaghetti Code: classe com métodos longos sem parâmetros, tipicamente programação procedural em OO.

15

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Clonagem dos 200 repositórios a partir do github

• Cada repositório é analisado por uma ferramenta chamada History Miner

16

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Para cada classe infectada com algum tipo de Code Smell, são contados o número de commits entre a introdução da classe no Sistema e o commit detectado pelo Decor como Code Smell

17

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Restrição a dois possíveis cenários:

18

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Em casos de Smells que são resultados de diversas manutenções no código-fonte, o History Miner computa um conjunto de métricas qualitativas para cada snapshot de uma classe.

• A intenção é compreender se as tendências destas métricas diferem entre classes afetadas por algum Code Smell e classes não afetadas por nenhum Code Smell. • Se o Smell surge rapidamente ou gradualmente no decorrer dos commits.

19

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Função que obtém uma melhor aproximação da distribuição dos dados

• Comparação das distribuições com o teste de Mann-Whitney U

• Observada a magnitude das diferenças (classes clean e smelly) com Cliff’s Delta

20

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• BLOB

• LOC inclinação 295

vezes maior.

21

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Class Data Should be Large

22

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Complex Class

23

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Functional Decomposition

24

METODOLOGIA

3) Extração e análise de dados• 3.1) Quando os Code Smells são introduzidos?

• Spagheti Code

25

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

• Identificação dos Commits que contribuem para a infecção com algum Code Smell

• Foram obtidos 9164 commits chamados de “Smell Introducing”

26

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

• Cada commit chamado de “Smell Introducing” foi classificado com as regras abaixo

• Foi realizado o download das issues de todos os 200 projetos pelo JIRA e BUGZILLA

27

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

• Efetuar o link entre as issues e os commits• Expressões regulares combinando o ID da issue com as mensagens dos commits

• Uso da abordagem Re-Link (89% precision 78% recall)

• 95% (8693 commits) foram analisados manualmente• Datas dos major releases foram identificadas

pelas tags dos commits• Workload – quantos commits mensais cada

desenvolvedor realizou.• Owner – responsável por mais de 75% dos commitsem uma classe.• Newcomer – se os 3 primeiros commits feitos peloDesenvolvedor são “Smell Introducing”

28

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

• Analisada a porcentagem dos commits “Smell Introducing” classificados de acordo com as tags de cada categoria

• Commit goal

29

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

30

METODOLOGIA

3) Extração e análise de dados• 3.2) Por que os Code Smells são introduzidos?

31

AMEAÇAS À VALIDADE

• DECOR – possível presença de falsos positivos e falsos negativos;

• Análise da ocupação dos desenvolvedores descarta a possibilidade dos mesmos estarem atuando em mais de um projeto;

• Para análise do Smell Introducing commit, o primeiro commit de cada arquivo foi descartado, por vir diretamente de antigos controladores de versão;

• Algumas informações inconsistentes dos desenvolvedores no github;

• Casos onde classes foram afetadas por diferentes Code Smells ao mesmo tempo;

• Apenas 5 tipos de smell (restrições computacionais).

32

CONCLUSÕES

33