Desenvolvedores versus Ferramenta

Um dos objetivos desse estudo experimental é verificar se os desenvolvedores (participantes do estudo) concordam com classes e métodos infectados com code smells identificados por uma ferramenta de detecção. Portanto, esta seção tem como objetivo responder à seguinte questão de pesquisa especificada na Seção 4.1.

QP1. Os desenvolvedores concordam com os code smells identificados pela ferramenta em um sistema de software desenvolvido ou mantido por eles?

Comparando as classes e métodos detectados pela ferramenta com code smells e as respostas dos participantes, o Questionário I nos mostrou que não houve consenso entre a ferramenta e todos os participantes na análise de nenhuma classe. No entanto, ao comparar as respostas dos participantes e a análise da ferramenta, verificamos que o participante P1 foi o que mais se aproximou da ferramenta com a identificação de quatro das sete classes apontas pela ferramenta, seguido do participante P4 com três classes e os participantes P2 e P3 com duas classes cada um.

99

O participante P1 teve mais facilidade em identificar classes com os code smells Data Class, Refused Bequest e Shotgun Surgery. Já o participante P2 teve mais facilidade em identificar classes com Shotgun Surgery, Refused Bequest e God Class. Enquanto o participante P3 teve facilidade em identificar classes com os quatro code smells (Shotgun Surgery, Refused Bequest, God Class e Data Class). E, o participante P4, assim como o participante P3, também teve facilidade em identificar classes com os quatro code smells (Shotgun Surgery, Refused Bequest, God Class e Data Class)

Contudo, todos os participantes conseguiram identificar pelo menos uma classe com Refused Bequest e Shotgun Surgery. Isso se deve ao fato de que, classes com o code smell Refused Bequest possui uma característica um tanto fácil de identificar no código-fonte que é o uso de métodos e atributos das classes herdadas. O mesmo ocorre nas classes com o code smell Shotgun Surgery, onde também é um tanto fácil identificar classes cuja modificação implica em muitas pequenas modificações em muitas outras classes.

No que tange a identificação dos métodos com code smells, constatamos que não houve nenhum método em que houvesse consenso entre a ferramenta e todos os participantes. Em geral, a ferramenta detectou seis métodos com o code smell Feature Envy, o participante P1 identificou nove métodos, o participante P2 identificou cinco métodos, o participante P3 identificou quatro métodos e o participante P4 identificou dois métodos.

Especialmente para o participante P1, métodos com o code smell Feature Envy foram fáceis de identificar, visto que ele identificou a ocorrência do Feature Envy nove métodos. Os participantes P2 e P3 não tiveram muita dificuldade ao identificar métodos com esse code smell, no entanto o participante P4 foi o que mais teve dificuldade ao identificar métodos com o code smell Feature Envy (identificou apenas dois).

Os resultados do Questionário I mostraram que os participantes entenderam os conceitos apresentados durante o treinamento e foram capazes de identificar code smells em classes e métodos sem ajuda de uma ferramenta.

Desta forma, nosso próximo passo era verificar se os participantes concordam com classes e métodos identificados por uma ferramenta de detecção como code smells, para isso utilizamos o Questionário II.

Como apresentado na Seção 4.5.3, o Questionário II é composto por três questões. A questão utilizada para nos ajudar a responder a questão de pesquisa QP1 foi à letra “a” que

100

diz: “A ferramenta apontou que essa classe ou método possui o code smell indicado. Você concorda com a ferramenta, ou seja, em sua opinião essa classe ou método possui esse code smell? Por quê? (se você concorda, por favor, responda as letras “b” e “c”)”.

Assim como fizemos na divulgação dos resultados na Seção 4.6.2, aqui também dividiremos as análises em subseções, onde, cada subseção corresponde a um code smell.

God Class

Ao examinarmos as respostas dos participantes, quando questionados a cerca das classes apontadas pela ferramenta como God Class, verificamos que o participante P1 concordou com a detecção da ferramenta em cinco das 10 classes apresentadas. Assim como a ferramenta de detecção, o participante P1 classifica classes que centralizam muito trabalho, detém muitas responsabilidades, são grandes e complexas com o code smell God Class.

O participante P2 concordou com a detecção da ferramenta em seis das 10 classes apresentadas. Para esse participante, classes que possui muitas funcionalidades em um só lugar, que são grandes, complexas e centralizam muito trabalho são God Class.

O participante P3 foi o que mais concordou com a detecção da ferramenta, oito das 10 classes apresentadas. Semelhante ao participante P1 e P2, o participante P3 também julga como características próprias a God Class, classes que realizam muito trabalho, são grandes, complexas e abrigam muitas funções em um só lugar.

Assim como o participante P2, o participante P4 concordou com a detecção da ferramenta em cinco das 10 classes apresentadas. Para esse participante, classes que detém muitas responsabilidades, são complexas e realizam muito trabalho trata-se de God Class.

Data Class

Ao examinarmos as respostas dos participantes, quando questionados a cerca das classes apontadas pela ferramenta como Data Class, verificamos que o participante P1 concordou com a detecção da ferramenta em oito das 10 classes apresentadas. O principal argumento utilizado pelo participante P1 para concordar com as classes detectadas pela

101

ferramenta foi “essa classe só contém dados”, no entanto, ele também apontou características tais como, “pouco complexa”, “contém poucos serviços” e “realiza muito trabalho”.

O participante P2 concordou com a detecção da ferramenta em sete das 10 classes apresentadas. Para esse participante, classes que oferecem muitos dados e poucos serviços, classes usadas somente para conter dados (leitura e gravação de dados), classes que não apresentam funcionalidade própria e classes pouco complexas são características presentes em classes com Data Class.

O participante P3 foi o que menos concordou com a detecção da ferramenta, apenas duas das 10 classes apresentadas. Para esse participante, a classe só é uma Data Class se ela não apresenta funcionalidade própria e se possui variáveis de instância utilizadas por outras classes.

O participante P4 concordou com a detecção da ferramenta em seis das classes apresentadas. As características mais citadas por esse participante para julgar uma classe com Data Class foram: classes que oferece poucos serviços e classes usadas somente para leitura e gravação de dados.

Shotgun Surgery

Ao examinarmos as respostas dos participantes, quando questionados a cerca das classes apontadas pela ferramenta como Shotgun Surgery, verificamos que todos os participantes concordaram com a ferramenta sobre as 10 classes apresentadas.

Para o participante P1, classes que são utilizadas por muitas classes do sistema, onde uma alteração influencia no funcionamento de várias outras classes, e classes que contém muitas variáveis e que são bastante utilizadas por outras classes, são classes infectadas com o code smell Shotgun Surgery.

Para o participante P2, classes que possuem muitos dependentes, classes onde seus métodos são bastante utilizados por outras classes e classes que faz o papel de “mãe” de outras classes, são classes com Shotgun Surgery.

Já para o participante P3, classes que são muito utilizadas por outras classes e classes que são herdadas por muitas classes do sistema tratam-se de classes com Shotgun Surgery.

102

O participante P4 elegeu características bem parecidas com a do participante P2 para identificar classes com Shotgun Surgery, tais como: “classe mãe de muitas outras classes” e “classes que guardam importantes funções usadas por todo sistema”.

Refused Bequest

Ao examinarmos as respostas dos participantes, quando questionados a cerca das classes apontadas pela ferramenta como Refused Bequest, verificamos que o participante P1 concordou com três das 10 classes apresentadas pela ferramenta. O participante P1 elege classes que não usam praticamente nada da classe herdada, classes que usam poucos métodos herdados de suas superclasses e classes que herdam muitos métodos da sua superclasse, mas só utiliza um, como Refused Bequest.

O participante P2 concordou com sete das 10 classes apresentadas pela ferramenta. Para esse participante, a única característica apontada por ele ao julgar uma classe como Refused Bequest é: classes que herdam muitos métodos de suas superclasses mais não utilizam quase nada.

Semelhantemente ao participante P2, os participantes P3 e P4 também concordaram com a ferramenta em sete das 10 classes apresentadas, cada um, e também apontaram classes com Refused Bequest àquelas que utilizam pouco os métodos herdados das suas superclasses.

Feature Envy

Ao examinarmos as respostas dos participantes, quando questionados a cerca dos métodos apontados pela ferramenta como Feature Envy, verificamos que todos os quatro participantes concordaram com todos os 10 métodos apresentados pela ferramenta.

Para o participante P1, métodos que interagem e se interessam mais nos dados de outras classes, são métodos infectados pelo code smell Feature Envy. Já o participante P2,

103

acredita que o code smell Feature Envy está presente em métodos que parecem não pertencer a sua própria classe de tanto que acessa dados de outras classes.

Para o participante P3, métodos que utiliza muito os atributos e variáveis de outras classes são métodos com o smell Feature Envy. Semelhante ao participante P2, o participante P4 acredita que métodos que quase não usa nada da sua classe e que fica buscando dados em várias outras classes, mostra que esse método deveria estar em outro lugar, logo se trata de um método com Feature Envy.

A Tabela 16 apresenta de forma resumida a quantidade de classes e métodos que cada participante concordou com a ferramenta de detecção.

Tabela 16. Quantidade de classes e métodos que cada participante concordou com a ferramenta de detecção

Os resultados obtidos indicam que, os desenvolvedores/participantes concordam com os code smells identificados através de uma ferramenta de detecção em um sistema de software desenvolvido/mantido por eles. No entanto, os resultados enfatizam que o nível de consentimento com a ferramenta é mais do que satisfatório quando são analisadas classes com Shotgun Surgery e métodos com Feature Envy.

Esses resultados podem ser explicados, devido às características fáceis de serem identificadas em classes com o smell Shotgun Surgery, tais como: seus métodos são muito utilizados por outras classes, e elas têm muitas outras classes como clientes. Da mesma forma ocorre em métodos com o smell Feature Envy, onde, existem características que podem ser facilmente identificadas, tais como: métodos que parecem estar mais interessados nos dados Participante 1 (P1) Participante 2 (P2) Participante 3 (P3) Participante 4 (P4)

God Class 5 6 8 5

Data Class 8 7 2 6

Shotgun Surgery 10 10 10 10

Refused Bequest 3 7 7 7

Feature Envy 10 10 10 10

Concorda com a ferramenta? (em quantidade) Code Smell

104

de outras classes do que na sua própria classe, e métodos que acessam diretamente ou através de métodos de acesso muitos dados de outras classes.

Os resultados também enfatizam uma maior dificuldade em analisar classes com os code smells God Class e Data Class. Esses resultados podem ser explicados, devido à natureza um pouco mais complexa (quando comparado aos code smells Shotgun Surgery e Feature Envy) das características que envolvem essas anomalias. No caso do code smell God Class, características como: classes que implementa muitos interesses, classes grandes e complexas, classes que detém muitas responsabilidades e centraliza muito trabalho, criam um pouco de confusão nos desenvolvedores, pois surgem questionamentos do tipo: “Como mensurar o tamanho de uma classe?” e “Essa classe precisa ser complexa, devido as suas responsabilidades. Nesse caso toda classe assim é uma God Class?”. Semelhantemente ocorre em classes com o code smell Data Class, onde existem características não tão fáceis de mensurar, tais como: classes que não definem funcionalidade própria, classes que possuem atributos e métodos de acesso utilizados por muitas outras classes e classes pouco complexas.