[pt] Um dos principais sintomas de declínio da qualidade arquitetural em projetos de software é a manifestação contínua de anomalias de código. Quando estas anomalias não são detectadas e removidas com antecedência, a capacidade de evoluir e manter estes sistemas pode ser comprometida, e, eventualmente, uma reestruturação completa de suas arquiteturas é inevitável. Apesar da existência de diversas técnicas e ferramentas para detecção automática de anomalias de código, a identificação de anomalias que efetivamente causam problemas arquiteturais é ainda uma tarefa desafiadora e não trivial. Ademais, estudos realizados no contexto desta dissertação ostraram que desenvolvedores tendem a refatorar mais frequentemente anomalias que não causam problemas arquiteturais. Em especial, percebeu-se que desenvolvedores priorizam a refatoração de elementos de código que não afetam a arquitetura dos sistemas, como métodos privados ou módulos internos de um componente arquitetural. Neste contexto, o presente trabalho propõe uma abordagem para priorização de anomalias de código. Esta abordagem é composta por heurísticas que exploram diferentes fatores para identificar e ordenar as anomalias detectadas de acordo com suas relevâncias arquiteturais. Tais fatores compreendem desde a quantidade de mudanças realizadas no código ao longo da evolução dos sistemas, até os papéis arquiteturais por ele desempenhados. Foi ainda implementada uma ferramenta para aplicar tais heurísticas de priorização automaticamente em projetos Java. A abordagem proposta foi avaliada em 4 projetos de software de diferentes domínios. Tal avaliação revelou que mantenedores de software poderiam ser beneficiados pelas recomendações de priorização produzidas pela ferramenta, de modo a investir seus esforços de refatoração na solução de problemas arquiteturalmente relevantes. / [en] The progressive manifestation of code anomalies in a software system is a key symptom of its architecture quality decline. When those anomalies are not detected and removed early, the maintainability of software projects can be compromised irreversibly, and, eventually, a complete redesign is inevitable. Despite the existence of many techniques and tools for code anomaly detection, identifying anomalies that are more likely to cause architecture problems remains a challenging task. In fact, studies performed in the context of this dissertation show that even when there is tool upport for detecting code anomalies, developers seem to invest more time refactoring those that are not related to architectural problems. Moreover, we also found that developers frequently prioritize refactoring of code elements that do not contribute to a better adherence to the intended software architecture. In this context, this dissertation proposes a prioritization approach for identifying which anomalies in a system implementation are more harmful to the architecture. The proposed approach is composed of heuristic strategies that exploit several software project factors to identify and rank code anomalies by their architecture relevance. These factors range from the change characteristics to the potential architecture roles of software modules. Furthermore, we implemented tool support for applying our prioritization approach in Java projects. We also evaluated the prioritization approach on 4 software projects from different application domains. Our evaluation revealed that software maintainers could benefit from the recommended rankings for identifying which code anomalies are harming architecture the most, helping them investing their refactoring efforts into solving the architecturally relevant problems.

[pt] Code smells são estruturas pobres que prejudicam a manutenção do sistema. Sendo assim, code smells devem ser detectados e removidos, através de refatoração, no começo do ciclo de vida do software. Refatoração consiste em modificações no código que visam melhorar a manutenção do software, removendo ou mitigando estruturas pobres. Contudo, as estratégias de detecção e refatoração de smells são subjetivas. Isto é, desenvolvedores trabalhando no mesmo sistema podem divergir acerca da existência de um smell. Essa divergência é influenciada pelo conhecimento do desenvolvedor, incluindo o design do sistema e o código analisado. Como consequência, essa divergência afeta também a aplicação das refatorações. Assim, é preciso customizar a detecção de smell e refatoração a partir do conhecimento dos desenvolvedores. Afinal, o desenvolvedor é quem confirma a nocividade de um smell e define como refatorá-lo. Para isso, decompomos nossa pesquisa em 3 passos: (i) como customizar estratégias de detecção de smells?, (ii) se e com que frequência os desenvolvedores customizam suas refatorações? e (iii) como dar suporte a customização de refatoração?. No primeiro passo avaliamos as técnicas de aprendizagem de máquina quanto a capacidade de customizar sua detecção para cada desenvolvedor. Segundo, nós investigamos como desenvolvedores customizam refatorações, analisando suas modificações de código enquanto aplicam certos tipos de refatoração. Além disso, nós também discutimos como essas customizações estão relacionadas com a inserção, remoção ou mitigação de smells e se são apoiados pelo Eclipse. Terceiro, nós propusemos uma abordagem que permite a aplicação de refatorações customizadas. Nossos resultados indicaram que as técnicas de aprendizagem de máquina são capazes de capturar o conhecimento do desenvolvedor e obter alta acurácia detectando smells. Além disso, desenvolvedores frequentemente customizam refatorações que não são totalmente suportadas pelo Eclipse. Para piorar, customizações complexas, geralmente manuais, tendem a reduzir o efeito positivo da refatoração. Portanto, nossos resultados servem como base para melhorar o suporte de ferramentas: a (i) detecção customizada de smells, levando em consideração o conhecimento do desenvolvedor e (ii) a aplicação de refatoração customizada. / [en] Code smells are poor structures that harm software maintenance. Therefore, code smells should be detected and removed, through refactoring, early in the software lifecycle. Refactoring consists of a sequence of code modifications that aim to improve software maintenance by removing or mitigating poor code structures. However, the strategies for detecting and refactoring smells are subjective. Even developers working on the same software may diverge on their opinions about the existence of a smell. In fact, this divergence is mostly influenced by the developer s knowledge, including the system s design and the analyzed source code. As a consequence, the same divergence affects the application of the corresponding refactorings. Therefore, there is a need to support the customization of smell detection and refactoring based on the developer s knowledge. The developer is who, after all, becomes the decision maker on confirming the harmfulness of a smelly structure and how to refactor it out. In order to address this issue, we split our research in 3 steps: (i) how to customize smell detection strategies? (ii) whether and how often developers customize their refactorings? and (iii) how to support refactoring customization? In the first step, we evaluated the use of machine learning techniques for properly customizing smell detection for each developer. Second, we investigated how developers customize refactorings by analyzing their code modifications while applying certain refactoring types. Besides, we also discussed how these customizations are related to the introduction, removal or mitigation of smells, and whether they are currently supported by Eclipse, a popular IDE. Third, we proposed an approach that allows the application of custom refactoring. Our results indicated that machine learning techniques are able to efficiently capture the developer s knowledge and achieve high smell detection accuracy. Also, even though developers frequently customize refactorings, their customizations are often not supported by Eclipse. To make it worse, complex customizations, which are manually performed, tend to reduce the positive effect of the refactoring. Therefore, our contributions serve as a basis for improving tool support for: (i) customized detection of smells considering the developer s knowledge, and (ii) application of customized refactoring.

[pt] Um problema de projeto é a manifestação de uma ou mais decisões de projeto inadequadas que afetam negativamente requisitos não funcionais. Por exemplo, Fat Interface, um problema que indica quando uma interface expõe serviços não coesos, no qual dificulta a extensibilidade e a manutenibilidade de um sistema de software. Apesar de problemas de projeto serem prejudiciais aos sistemas, identificá-los é uma tarefa difícil, especialmente quando o código-fonte é o único artefato disponível. Embora pesquisadores venham investigando técnicas para ajudar os desenvolvedores a identificar problemas de projeto, há pouco conhecimento sobre o processo de identificar problemas de projeto. Por exemplo, anomalias de códigos, um indicador de problemas de projeto, têm sido usadas para ajudar desenvolvedores a identificar problemas de projeto. No entanto, ainda não sabemos se elas são suficientes para ajudá-los ou não. Em particular, nenhum estudo tentou entender como os desenvolvedores identificam problemas de projeto. Nesse contexto, nós realizamos alguns estudos para entender a identificação de problemas de projeto. Em nossos dois primeiros estudos, nós investigamos o papel que as anomalias de código desempenham durante a identificação de problemas de design. Nossos resultados indicam que as anomalias de código são relevantes para os desenvolvedores na prática, por exemplo, eles são relevantes para indicar elementos a serem refatorados. Apesar da relevância, descobrimos que as anomalias de código não são suficientes para ajudar os desenvolvedores a identificar problemas de projeto. Nesse sentido, conduzimos outro estudo para investigar quais outros indicadores os desenvolvedores usam na prática e como eles são usados. Este estudo resultou em uma teoria sobre como os desenvolvedores identificam problemas de projeto na prática. A teoria revela quais são os indicadores que os desenvolvedores usam, como eles usam esses indicadores e as características de tais indicadores que os desenvolvedores consideram úteis. Os resultados encontrados nos forneceram uma melhor compreensão do processo de identificação de problemas de projeto, abrindo caminho para a elaboração de técnicas mais eficazes em ajudar os desenvolvedores a identificar problemas de projeto. / [en] A design problem is the manifestation of one or more inappropriate design decisions that negatively impact non-functional requirements. For example, the Fat Interface, a problem that indicates when an interface exposes non-cohesive services, hampers the extensibility and maintainability of a software system. Despite its harmfulness, identifying a design problem in a system is difficult, especially when the source code is the only available artifact. Although researchers have been investigating techniques to help developers in identifying design problems, there is little or no knowledge about the process of identifying design problems. For instance, code smells, microstructures that are a surface indication of design problems, have been used in several techniques to support developers during the design problem identification. However, there is no knowledge if code smells suffice to help developers to identify design problems. In particular, no study has tried to understand how developers identify design problems in practice. Thus, in this thesis, we have conducted a series of studies to understand design problem identification. In our two first studies, we investigated the role that code smells play in supporting developers during the design problem identification. Our results indicate that code smells are relevant for developers in practice; for instance, they are relevant to indicate elements that need to be refactored. However, we found that code smells, despite their relevance, do not suffice in helping developers to identify design problems. In this vein, we conducted another study to investigate what indicators developers use in practice, and how they use them. This study resulted in a theory about how developers identify design problems in practice. For instance, the theory reveals the indicators that developers use, how they use these indicators, and the characteristics of such indicators that are perceived as helpful by developers. The results found by our studies provided us with a better understanding of the process of identifying design problems thitherto nonexistent. Moreover, our findings pave the way for the elaboration of more effective techniques to identify design problems in the source code.

[pt] O projeto de software resulta das decisões ao longo do seu desenvolvimento. Algumas dessas decisões podem levar a problemas de projeto, afetando negativamente os requisitos não funcionais (RNFs). Embora seja crucial identificar esses problemas, essa é uma tarefa complexa, especialmente quando o código-fonte é o único artefato disponível. Nessa tarefa, os desenvolvedores podem ter que considerar vários sintomas (por exemplo, anomalias de código) para identificar até mesmo um único problema de projeto. Estudos anteriores sugerem que usar um único sintoma pode ser inadequado para identificar tais problemas. Portanto, nesta tese, investigamos como múltiplos sintomas podem ser usados nessa identificação. Em nosso primeiro estudo, nos concentramos em investigar o uso de anomalias de código bem conhecidos (anomalias de manutenabilidade). Nós identificamos que os desenvolvedores podem se beneficiar desse tipo de sintoma quando as ocorrências das anomalias afetam a mesma localização do programa e formam um padrão, podendo indicar melhor a presença de um problema de projeto. No entanto, também revelamos as limitações ao depender exclusivamente desse tipo de sintoma, destacando a necessidade de contexto adicional. Isso nos levou ao segundo estudo, onde investigamos um tipo adicional de sintoma, anomalias de robustez, e seu uso combinado com anumalias de manutenabilidade. Nós identificamos que ambos os tipos de anomalia de código podem ajudar os desenvolvedores na identificação de problemas de projeto principalmente relacionados à má modularização do sistema. Através desses dois estudos, observamos a necessidade de compreender as perspectivas e estratégias dos desenvolvedores em relação aos RNFs do sistema. Ao fazê-lo, podemos potencialmente entender quem são os desenvolvedores mais capazes de prevenir, discutir e identificar problemas de projeto. Isso nos levou ao terceiro estudo, onde investigamos como os desenvolvedores discutem e abordam RNFs em seus sistemas, revelando estratégias comuns em relação a esses requisitos. Esses resultados nos proporcionaram uma compreensão mais abrangente de como os desenvolvedores podem combinar diferentes sintomas e como percebem sua importância dentro de seus sistemas. / [en] Software design results from stakeholder decisions made through software development. Some of these decisions may lead to design problems, negatively impacting non-functional requirements (NFRs). Even though identifying design problems is crucial, this is a complex task, especially when the source code is the only artifact available. Along this task, developers may have to reason about multiple symptoms (e.g., code smells and nonconformities with NFRs) to identify even a single design problem. In fact, previous studies suggest that relying on a single symptom may be inadequate for the design problem identification. Thus, in this thesis, we investigate the role that the use of multiple symptoms may have on the identification of design problems. In our first study, we focused on investigating the use of well-known code smells (called here maintainability smells) to support this task. Our results indicated that developers could benefit from this type of symptom when smell occurrences affect the same program location and form a pattern; i.e., a set of co-occurring maintainability smells may better indicate the presence of a design problem. Nevertheless, we also reveal the limitations of relying solely on this type of symptom, highlighting the need for additional context. This leads us to the second study, where we investigate an additional type of symptom, robustness smells, and its combined use with maintainability smells. Our results indicated that the use of both types of smells can help developers in the identification of design problems mainly related to bad modularization of the system (e.g. excess of responsibilities assigned to the same component). Through these two studies, we observed the need to understand the perspectives and strategies of developers toward the NFRs of the system. In doing so, we can potentially understand who are the developers better able to prevent, discuss and identify design problems. That led us to our third study, where we investigated how developers discuss and address NFRs in their systems, uncovering common strategies toward these requirements. These results led us to a more comprehensive understanding of how developers can combine different symptoms and how they perceive their significance within their systems.

[pt] Em um sistema de software, as anomalias de código indicam problemas estruturais que podem ser resolvidos através da refatoração. No entanto, desenvolvedores podem negligenciar ou acabar criando novas anomalias ao refatorar. Pouco foi relatado sobre os efeitos benéficos e prejudiciais da refatoração de anomalias de código. Evidências sugerem que os desenvolvedores frequentemente precisam aplicar uma sequência de refatorações (refatoração em lote) para remover completamente as estruturas anômalas. Assim, nesta tese, realizamos uma série de estudos para entender o impacto de refatorações simples e em lote em anomalias de código. Em nossos primeiros estudos, analisamos com que frequência os tipos de refatoração comumente usados afetam a densidade de anomalias ao longo das histórias de dezenas de projetos. Mesmo que 79,4 por cento das refatorações tenham tocado em elementos anômalos, 57 por cento não reduziram suas ocorrências. Surpreendentemente, apenas 9,7 por cento das refatorações removeram anomalias de código, enquanto 33 por cento induziram a introdução de novas. Por um lado, observamos padrões nocivos de introdução de anomalias. Por outro lado, observamos que muitas anomalias podem ser removidas apenas por refatorações em lote. Assim, nossos últimos estudos investigam o impacto de refatorações em lote nas anomalias. Mesmo quando aplicadas em lotes, as refatorações tendem a não afetar ou mesmo aumentar a densidade de anomalias. Também identificamos padrões entre tipos de lotes e tipos de anomalias, levando-nos à criação de heurísticas que podem orientar os desenvolvedores durante tarefas de remoção de anomalias de código. O último estudo avaliou essas heurísticas e concluímos que os resultados são promissores. / [en] Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. However, developers may neglect or end up creating new code smells through single refactoring. Little has been reported about recurring beneficial and harmful effects of refactoring on the program structural quality. As a consequence, developers still miss guidance along non-trivial smell-removing tasks. In fact, evidence suggests developers often need to apply a sequence of refactorings, so-called batch refactoring, to entirely remove a smelly code structure. Thus, in this thesis, we have conducted a series of studies to understand the impact of single and batch refactorings on code smells. In our first studies, we analyze how often commonly-used types of single refactoring affect the density of code smells along the version histories of dozens of projects. Even though 79.4 percent of the refactorings touched smelly elements, 57 percent had no impact on the smell removal. Surprisingly, only 9.7 percent of refactorings removed smells, while 33 percent induced the introduction of new ones. On one hand, we observed that harmful refactoring-smell patterns could be used to guide developers to avoid smell-inducing refactoring. On the other hand, we observed that many smells can be removed only through batch refactoring. Thus, our last studies investigate the impact of batch refactorings on smells. Even when applied in batches, refactorings tend to maintain or even increase the density of code smells. We also identified common batch-smell patterns, which enable us to create heuristics that can guide developers through smell-removing tasks. The last study evaluated those heuristics, and we conclude the outcomes are promising.

[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] Os elementos de código geralmente mudam ao longo da evolução do sistema, o que implica em uma eventual degradação estrutural do código fonte. Sintomas recorrentes de tal degradação são chamados anomalias de código. Estudos sugerem que quanto mais anomalias de código afetam um sistema, mais alta se torna a propensão a bugs dos elementos de código. Para lidar com tal degradação da qualidade estrutural do código, desenvolvedores geralmente aplicam refatorações no código fonte. No entanto, aplicar refatorações pode não ser suficiente para reduzir a propensão a bugs dos elementos de código degradados. Um estudo recente sugere que refatorações induzem bugs frequentemente. No entanto, os autores não analisam se o código refatorado está, de fato, diretamente relacionado à introdução de bugs. Com isso, nesta dissertação, realizamos dois estudos longitudinais de múltiplos projetos para avaliar a propensão a bugs do código refatorado. Nossa metodologia teve como objetivo abordar várias limitações de estudos anteriores. Por exemplo, definimos duas propriedades complementares da propensão a bugs do código refatorado, sendo elas, frequência e distância. Enquanto a primeira propriedade quantifica a frequência com que um código refatorado está relacionado a bugs que emergiram no código fonte, a distância quantifica o quão próximo um bug surge depois que uma refatoração é aplicada. Nosso primeiro estudo tem como objetivo avaliar a propensão a bugs de refatorações isoladas. Primeiro, nossos resultados mostram que 80 porcento dos elementos degradados que se tornaram bugs não foram previamente refatorados. Este resultado implica que um código refatorado é menos propenso a bugs do que um código não refatorado. Em segundo lugar, em 75 porcento das vezes um bug surge depois de 7 mudanças feitas a partir da operação de refatoração, o que geralmente corresponde à 3 meses nos projetos analisados. Nosso segundo estudo tem como objetivo avaliar a propensão a bugs de refatorações em lote, ou seja, refatorações aplicadas em sequência. Nossos resultados mostram que, na maioria dos casos, o código refatorado em lotes é mais resiliente à introdução de bugs do que o código refatorado por meio de refatorações isoladas. / [en] Programs often change along the system evolution, which implies an eventual code structure degradation. Recurring symptoms of such degradation are code smells. Studies suggest that the more frequently code smells affect a system, the higher becomes the bug-proneness of the code elements. To tackle code structural quality degradation, developers often apply refactorings on smelly program elements. However, applying refactorings might not suffice to reduce the bug-proneness of such degraded program elements. Previous empirical studies do not systematically analyze the bug-proneness of refactored code. Even though a recent study suggests that refactoring induces bugs frequently, the authors do not analyze to what extent refactored code is indeed closely related to the bug occurrence. Thus, in this dissertation, we conducted two longitudinal multi-project studies to assess the bugproneness of refactored code. Our methodology aimed to address various limitations of previous studies. For instance, we have defined two complementary properties of the bug-proneness of refactored code, i.e., frequency and distance. While the former quantifies how often a refactored code is related to emerging bugs, the latter quantifies how close a bug emerges after a refactoring has been applied. The quantitative analysis of such properties was complemented by a manual analysis of refactorings closely related to the bug occurrence. Our first study aims at assessing the bug-proneness of code refactored through isolated refactorings, i.e., a single refactoring operation not performed in conjunction with other refactoring operations. This study reveals that 80 per cent of the smelly elements that became buggy were not previously refactored. This result suggests the refactored code is much less bug-prone than non-refactored code. Moreover, in 75 per cent of the times, a bug emerges in 7 changes far from the refactoring operation; this amount of changes usually corresponds to 3 months in the analyzed projects. Our second study aims at assessing the bug-proneness of code elements refactored through batch refactorings, i.e., a sequence of inter-related refactoring operations. Our results show that code refactored through batches is often more resilient to the introduction of bugs as compared to code refactored through isolated refactorings.

[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.

[pt] Sistemas impactados por Problemas de Projeto (PPs) podem se tornar difíceis de manter e evoluir. A identificação de PPs pode ocorrer por meio de múltiplos sintomas, tais como code smells. Após tal identificação, pode-se remover os PPs por meio de refatorações. No entanto, decidir onde e como refatorar é uma tarefa desafiadora. Assim, técnicas de recomendação de refatoração têm sido propostas. Apesar disso, ainda há pouco consenso sobre quais requisitos devem ser atendidos por elas. Nesta tese, estamos propondo quatro requisitos empiricamente identificados que tais técnicas devem seguir. Primeiro, cada PP geralmente está relacionado a vários tipos de sintomas no código-fonte e eles devem ser considerados juntos para gerar recomendações. Além disso, uma técnica de recomendação deve permitir a seleção de contextos específicos para refatoração. Quarto, também deve-se considerar as funcionalidades modificadas para criar recomendações úteis. Finalmente, os desenvolvedores nem sempre conduzem as refatorações mais eficazes na prática, muitas vezes inconscientemente, resultando na remoção incompleta de PPs. Assim, eles precisam de assistência para remover os PPs. Existem apenas técnicas que atendem parcialmente aos requisitos mencionados. Sendo assim, nós propomos a técnica OrganicRef. OrganicRef destina-se a ajudar os desenvolvedores na remoção de PPs em seus contextos de interesse. OrganicRef encontra as funcionalidades dos elementos de código usando um algoritmo de modelagem de tópicos. Em seguida, ele coleta múltiplos tipos de sintomas que afetam os elementos do código. Para recomendar refatorações, OrganicRef combina heurísticas baseadas em regras e baseadas em funcionalidades. OrganicRef também aplica otimização baseada em busca para derivar várias recomendações possíveis. Para avaliar o OrganicRef, realizamos um estudo experimental com seis projetos de software. Os resultados mostraram que as recomendações do OrganicRef melhoram significativamente a qualidade dos elementos refatorados. / [en] Software projects impacted by Design Problems (DPs) may become difficult to maintain and evolve. The identification of DPs may occur through symptoms such as code smells. After such identification, developers can remove the DPs through refactorings. However, deciding where and how to refactor is a challenging task. Thus, several refactoring recommendation techniques have been proposed. Nevertheless, there is still little consensus on which requirements must be satisfied by them. In this thesis, we are proposing four empirically identified requirements that any DP removal technique should follow. First, each single DP is usually related with multiple types of symptoms in the source code and they should be considered altogether for generating recommendations. Second, a recommendation technique should allow the selection of possible candidate contexts for refactoring. Fourth, the technique should consider the features of undergoing changes to create useful recommendations. Finally, developers do not always conduct the most effective refactorings in practice, quite often unconsciously, resulting in the incomplete removal of DPs. Thus, they need assistance to remove DPs. There are techniques partially fulfilling the aforementioned requirements, though none satisfactorily meets them all. Thus, we propose the OrganicRef technique. OrganicRef is intended to help developers in removing DPs in their contexts of interest. OrganicRef finds the contexts by capturing the features affecting relevant code elements using a topic modeling algorithm. Then, it collects multiple symptom types affecting the code elements. To recommend effective refactorings, OrganicRef combines rulebased and feature-driven heuristics. It also uses search-based optimization to derive multiple possible recommendations. To evaluate OrganicRef, we conducted an empirical study with six open source projects. Results showed that OrganicRef recommendations significantly improves the design of refactored elements.