[pt] Desenvolvedores frequentemente aplicam refatoração para melhorar os atributos internos de qualidade em projetos de software, tais como acoplamento e tamanho. Chamamos de rerrefatoração quando desenvolvedores refatoram um elemento de código-fonte previamente refatorado. O conhecimento empírico é limitado acerca de até que ponto refatoração e rerrefatoração de fato melhoram os atributos internos de qualidade. Nesta dissertação, nós investigamos a limitação supracitada com base em cinco atributos internos de qualidade conhecidos: acoplamento, coesão, complexidade, herança e tamanho. Também nos baseamos no histórico de versionamento de 23 projetos de software de código-fonte aberto, os quais possuem 29,303 operações de refatoração e 49.55 por cento de rerrefatorações. Nossa análise revelou descobertas interessantes apresentadas como segue. Primeiro, desenvolvedores aplicam mais de 93.45 por cento de operações de refatoração e rerrefatoração sobre elementos de código-fonte com ao menos um atributo interno de qualidade crítico, contrariando trabalhos anteriores. Segundo, para 65 por cento das operações, os atributos internos de qualidade relacionados melhoram, enquanto que os demais 35 por cento permanecem não-afetados. Terceiro, sempre que operações de refatoração são aplicadas sem mudanças adicionais no código fonte, o que chamamos de operação de refatoração root-canal, os atributos internos de qualidade frequentemente melhoram, ou ao menos, não pioram. Ao contrário, 55 por cento das operações de refatoração aplicadas com mudanças adicionais, tais como correção de bugs, surpreendentemente melhoram os atributos internos de qualidade, com somente 10 por cento de piora, o que também é válido para rerrefatoração. Nós sumarizamos nossas descobertas na forma de recomendações para desenvolvedores e pesquisadores. / [en] Developers often apply code refactoring to improve the internal quality attributes of a program, such as coupling and size. Given the structural decay of certain program elements, developers may need to apply multiple refactorings to these elements to achieve quality attribute improvements. We call re-refactoring when developers refactor again a previously refactored element in a program, such as a method or a class. There is limited empirical knowledge on to what extent developers successfully improve internal quality attributes through (re-)refactoring in their actual software projects. This dissertation addresses this limitation by investigating the impact of (re-)refactoring on five well-known internal quality attributes: cohesion, complexity, coupling, inheritance, and size. We also rely on the version history of 23 open source projects, which have 29,303 refactoring operations and 49.55 percent of re-refactoring operations. Our analysis revealed relevant findings. First, developers apply more than 93.45 percent of refactoring and re-refactoring operations to code elements with at least one critical internal quality attribute, as oppositely found in previous work. Second, 65 percent of the operations actually improve the relevant attributes, i.e. those attributes that are actually related to the refactoring type being applied; the remaining 35 percent operations keep the relevant quality attributes unaffected. Third, whenever refactoring operations are applied without additional changes, which we call root-canal refactoring, the internal quality attributes are either frequently improved or at least not worsened. Contrarily, 55 percent of the refactoring operations with additional changes, such as bug fixes, surprisingly improve internal quality attributes, with only 10 percent of the quality decline. This finding is also valid for re-refactoring. Finally, we also summarize our findings as concrete recommendations for both practitioners and researchers.

[pt] A refatoração de código é uma transformação de código que visa aprimorar a estrutura interna do código. Uma refatoração isolada raramente é suficiente para remover completamente uma estrutura de código ruim, como uma anomalia de código. Os desenvolvedores então aplicam refatorações compostas para remover totalmente uma anomalia de código. Uma refatoração composta consiste em duas ou mais refatorações inter-relacionadas. Um refatoração composta é considerada completa quando elimina totalmente a anomalia de código alvo. Estudos relatam que os desenvolvedores geralmente falham em remover completamente as anomalias de código alvo por meio de refatorações compostas. Refatorações compostas concluídas podem não ser totalmente benéficas para a estrutura do código. Pois, estas podem induzir efeitos colaterais, como a introdução de anomalias de código ou a propagação de anomalias existentes. Há uma compreensão limitada sobre a completude das refatorações compostas e seus possíveis efeitos colaterais. Esta tese investiga como as refatorações compostas removem totalmente as anomalias de código sem induzir efeitos colaterais. Descobrimos que 64 por cento das refatorações compostas completas são formadas por tipos de refatoração não recomendados anteriormente. Dessa forma, derivamos um catálogo de recomendações para apoiar os desenvolvedores na aplicação de refatorações compostas. Na avaliação do catálogo, 85 por cento de 21 desenvolvedores relataram que usariam as recomendações do catálogo e que suas próprias soluções de refatoração teriam induzido efeitos colaterais. Também avaliamos qualitativamente três abordagens existentes para recomendar automaticamente refatorações compostas. Nesse estudo, a maioria (80 por cento) dos 10 desenvolvedores relatou que as abordagens existentes frequentemente induzem efeitos colaterais. No geral, as descobertas e o catálogo proposto podem ajudar os desenvolvedores a realizar refatorações compostas completas. / [en] Code refactoring is a code transformation that aims to enhance the internal code structure. A single refactoring is rarely sufficient to achieve the full removal of a poor code structure, such as a code smell. Developers then apply composite refactorings to fully remove a code smell. A composite refactoring (or, simply, composite) consists of two or more interrelated single refactorings. A composite is considered complete when it fully eliminates the target smell. However, studies report that developers often fail in completely removing target code smells through composites. Even when composite refactorings are complete they may still not be entirely beneficial to the code structure. They may induce side effects, such as the introduction of new smells or the propagation of existing ones. There is a limited understanding of the completeness of composite refactorings and their possible effects on structural quality. This thesis investigates whether and how composite refactorings fully remove smells without inducing side effects. We found that 64 per cent of complete composites in several software projects are formed of refactoring types not previously recommended in the literature. Based on this study, we derived a catalog of recommendations for supporting developers in applying composite refactorings. Out of twenty one developers evaluating our catalog, 85 per cent reported that they would use the catalog recommendations and that their own refactoring solutions would have induced side effects. We also qualitatively evaluated three existing approaches to automatically recommend composite refactorings. In our study with ten developers, most (80 per cent) developers reported that existing approaches frequently induce side effects. Overall, the findings and the proposed catalog can help developers to perform complete composite refactorings with better awareness of possible side effects.

[pt] Mesmo com o processo de refatoração sendo investigado cada vez mais nos últimos anos, muitas de suas características se mantém pouco compreendidas. Refatoração de software é o processo de melhorar a manutenibilidade de um sistema por meio de mudanças estruturais que não alteram seu comportamento. Estudos recentes revelaram que projetos de software frequentemente recebem refatorações compostas. Em tais refatorações, desenvolvedores aplicam uma série de transformações únicas em conjunção e em um único commit, e se espera que estas refatorações tenham um efeito maior e mais positivo do que refatorações singulares. Porém, refatorações frequentemente causam mudanças que ou mantém a qualidade do software da mesma forma, ou causam a piora do mesmo, levando trabalhos recentes a procurar causas em potencial para este comportamento. Porém, o porquê da complexidade destas mudanças compostas frequentemente afetarem seus resultados de alguma forma positiva ou (inesperadamente) negativa continua não investigado. O mesmo ocorre com o potencial efeito das preocupações dos desenvolvedores durante a aplicação de refatorações. Sobre estas preocupações, alguns trabalhos anteriores foram desenvolvidos em torno da caracterização e detecção de discussões de desenvolvedores relacionadas a refatorações. Porém, não se sabe se e como estas preocupações de desenvolvedores com refatorações, tornando-se explícitas em tais discussões, podem influenciar os efeitos de refatorações em um sistema. Portanto, este trabalho apresenta dois estudos com o objetivo de preencher a lacuna no conhecimento de que causas levam aos efeitos não-positivos frequentemente encontrados em refatorações, procurando entender: (i) se refatorações mais complexas realmente são mais efetivas do que refatorações simples, como esperado; (ii) em que situações desenvolvedores tendem a explicitar suas preocupações com refatoração do código; e (iii) qual é o impacto de tais preocupações na efetividade de uma refatoração em melhorar a qualidade estrutural do código. Nós analisamos estas características e atingimos os seguintes resultados: Primeiro, conforme a complexidade das refatorações aumenta, a efetividade das mesmas aumenta conjuntamente. Segundo, há uma relação entre a efetividade de refatorações e preocupações explícitas com refatorações, onde a possibilidade de efeitos negativos é menor quando desenvolvedores estão explicitamente preocupados com refatoração. Finalmente, desenvolvedores tendem a explicitar mais frequentemente suas preocupações com o processo de refatoração quando deparados com tarefas de refatoração mais complexas. / [en] Even though the refactoring process has been increasingly investigated in the last years, many of its characteristics remain poorly understood. Software refactoring is the process of improving the maintainability of a system through structural changes that do not alter its behaviour. Recent studies revealed that software projects frequently have to undergo composite refactorings. In such refactorings, developers perform a series of single transformations in conjunction and in a single commit, which are expected to have a larger and more positive impact than single refactorings. However, refactorings frequently cause changes that either keep the software quality the same, or cause it to worsen, which lead recent works to look for potential causes of this behavior. However, the complexity of these composite changes often affecting their outcomes in some positive or (unexpectedly) negative way remains not investigated, much like the developers concerns while performing refactoring. For the latter, some previous work was performed around characterizing and detecting refactoring-related developer discussions. However, it is unknown whether and how developers refactoring concerns made explicit in such discussions can influence the refactorings effects on a system. Thus, this work reports two studies aimed at bridging some of those gaps in knowledge in which causes lead to the non-positive effects frequently found in refactoring, by understanding: (i) if more complex refactorings are indeed more effective than simple refactorings, as one would expect; (ii) in which situations developers tend to have explicit concerns while refactoring the code; and (iii) what is the impact of such concerns on the effectiveness of a refactoring to improve structural quality. We analyze these characteristics and reach the following results: First, as refactoring complexity increases, the effectiveness of such refactorings increases as well. Second, there is a relationship between refactoring effectiveness and explicit refactoring concerns, in which the possibility of negative effects is lower when developers are explicitly concerned about refactoring. Finally, developers tend to be more explicit about their concerns on the refactoring process when they are faced with more complex refactoring tasks.

[pt] Contexto: Várias mudanças de código aplicadas ao evoluir funcionalidades visam melhorar atributos internos de qualidade como coesão. Tais mudanças são as refatorações. Refatorações não dirigidas podem piorar, e não melhorar, atributos internos. Porém, o saber atual é insuficiente para gerir atributos internos durante a evolução do sistema. Objetivo: Nosso primeiro objetivo é entender como refatorações afetam atributos internos ao evoluir sistemas, mitigando limitações de escopo de estudos anteriores. Nosso segundo objetivo é atender uma carência por evidência quantitativa sobre como gerir atributos internos críticos via refatorações ao evoluir sistemas. Um atributo interno é crítico se sua medição assume valores anômalos. Baixa coesão é um exemplo de atributo crítico. Método: O primeiro estudo estende uma avaliação quantitativa da relação entre refatorações e cinco atributos internos: acoplamento, coesão, complexidade, herança e tamanho. Incluímos novas análises e resolvemos ameaças à validade da literatura. O segundo estudo contém estudos de caso qualitativos baseados em grupo focal. Em dois casos industriais, promovemos discussões sobre o quanto (e por que) atributos críticos são relevante ao evoluir funcionalidades. Por fim, cruzamos os achados dos dois estudos para discutir como gerir atributos críticos via refatoração ao evoluir funcionalidades. Resultados: Aproximadamente 64 por cento das refatorações melhoram ou não afetam os atributos internos. Desenvolvedores parecem refatorar até melhorar os atributos mais relevantes, ignorando outros atributos internos possivelmente críticos. Baixa coesão e alta complexidade são percebidos como relevantes e tornam mais difícil evoluir funcionalidades. Alto acoplamento, herança larga e tamanho largo são percebidos como irrelevantes ao implementar funcionalidades especialmente complexas, por exemplo. Ao cruzar dados entre estudos, discutimos como refatorações podem melhorar atributos internos, inclusive atributos críticos. Conclusões: Os achados dos nossos estudos podem apoiar a gestão de atributos críticos relevantes aos desenvolvedores, mas também preservar outros atributos que podem se tornar críticos. / [en] Context: Several software changes applied while evolving software features aim at improving internal quality attributes, e.g. cohesion. These changes are the refactorings. Non-assisted refactorings might worsen, rather than improve, internal attributes. However, current knowledge is insufficient for managing internal attributes during software evolution. Objective: Our first objective is assessing how refactorings affect internal attributes during software evolution by filling gaps of past work on study scope. Our second objective is filling gaps of qualitative evidence on how to manage critical internal attributes via refactorings while evolving features. An internal attribute is critical when its measurement has anomalous values. Low cohesion is an example of critical attribute. Method: Our first study extends a large quantitative assessment of the relationship between refactorings and five internal attributes: cohesion, complexity, coupling, inheritance, and size. We include a more detailed statistical analysis and address major threats to validity of past work. Our second study is a qualitative case study based on focus group. We selected two industry cases to promote discussions on how much (and why) critical attributes are relevant while evolving features. Finally, we crossed the findings from both conducted studies aimed at discussing how critical attributes can be addressed via refactoring when evolving features. Results: About 64 per cent of refactorings either improve or keep the internal attributes unaffected. Developers seem to perform refactorings until the most relevant internal attributes are improved, thereby neglecting other internal attributes that may be critical. Low cohesion and high complexity are perceived as relevant because they often make evolving features harder than usual. High coupling, large inheritance, and large size are perceived as irrelevant when developers implement especially complex features. By crossing the findings from both studies, we discuss how refactorings can improve internal attributes, especially the critical ones. Conclusions: The findings of our studies can support managing critical attributes that developers typically find relevant, while preserving other attributes that may become critical.