The need for automated methods for identifying refactoring items is prelevent in many software projects today. Symptoms of refactoring needs is the concept of code smells within a software system. Recent studies have used single model machine learning to combat this issue. This study aims to test the possibility of improving machine learning code smell detection using ensemble methods. Therefore identifying the strongest ensemble model in the context of code smells and the relative sensitivity of the strongest perfoming ensemble identified. The ensemble models performance was studied by performing experiments using WekaNose to create datasets of code smells and Weka to train and test the models on the dataset. The datasets created was based on Qualitas Corpus curated java project. Each tested ensemble method was then compared to all the other ensembles, using f-measure, accuracy and AUC ROC scores. The tested ensemble methods were stacking, voting, bagging and boosting. The models to implement the ensemble methods with were models that previous studies had identified as strongest performer for code smell identification. The models where Jrip, J48, Naive Bayes and SMO. The findings showed, that compared to previous studies, bagging J48 improved results by 0.5%. And that the nominally implemented baggin of J48 in Weka follows best practices and the model where impacted negatively. However, due to the complexity of stacking and voting ensembles further work is needed regarding stacking and voting ensemble models in the context of code smell identification.

Submitted by Kleber Silva (kleberbs@ufba.br) on 2017-06-01T20:18:43Z No. of bitstreams: 1 Tese final - Amâncio.pdf: 4405750 bytes, checksum: ceb4c269d4cf1fa74d0861c679a6f10d (MD5) / Approved for entry into archive by Vanessa Reis (vanessa.jamile@ufba.br) on 2017-06-07T11:28:44Z (GMT) No. of bitstreams: 1 Tese final - Amâncio.pdf: 4405750 bytes, checksum: ceb4c269d4cf1fa74d0861c679a6f10d (MD5) / Made available in DSpace on 2017-06-07T11:28:44Z (GMT). No. of bitstreams: 1 Tese final - Amâncio.pdf: 4405750 bytes, checksum: ceb4c269d4cf1fa74d0861c679a6f10d (MD5) / Context: Code smell is a term commonly used to describe potential problems in the design of object-oriented systems. The theory about code smells, initially presented in nineties, is focused on characterization of different types of smells and heuristics for their detection and removal. Since then, empirical studies have evaluated the impact of the practical adoption of the code smell concept on software development. We call this issue the code smell effect. The findings of empirical studies on the code smell effect have presented inconsistencies with respect to what is expected by the theory. This phenomenon is not well understood. Objective: Enhancing the understanding of the code smell effect, characterizing problems hindering the practical adoption of the smell concept and investigating their origin. More specifically, we focus on the major confounding factor affecting observations on the code smell effect, which is the human role on smell detection. The human role is mostly disregarded by the theory and it strongly affects the experiments on the subject. Method: We explore the problem empirically, from two perspectives. First, we synthesize the current knowledge on the code smell effect from a set of primary studies published in the literature. To do this, we performed a systematic review based on thematic synthesis. Second, we propose the investigation of factors affecting the human evaluation of smells. To do this, we performed a family of controlled experiments. In it, we investigate an extensive number of factors affecting the human perception of smells. The factors are the use of design comprehension tool support; developer's experience, knowledge and training; and software size. From the thematic synthesis and the family of controlled experiments, we identify challenges for the area and present them as a research agenda. Results: We find out that human evaluation of smell should not be trusted. The studies indicate that the agreement on smell detection is low. They also show that demographic attributes, such as developers' experience, impact the agreement on smell detection. We also concluded that, nowadays, there are not evidences supporting the use of code smells for practical evaluation of design quality. Our evidences are divergent findings correlating code smells and software attributes, such as changes on source code. In some cases, the studies converge showing that code smells do not impact some attributes. This happens, for example, with studies correlating smells and effort on maintenance. Conclusion: This thesis points out to the gap between the theory and the experimental findings about the code smell effect. Our evidences indicate that the main source for this gap is the low number of studies focusing on the human role on the smell effect. The researches on the subject should focus on better understanding this issue. This not seems the path followed by the area, which has directed its effort on researches focused on tool assessments, such as automatic detection or smell removal. In order to face the problem, we propose a research agenda, indicating that the area needs to: i) investigate the nature of smells, grouping them according to their characteristics; ii) explore human factors affecting smell detection, and their relationships; iii) explore cognitive aspects affecting human perception of smells; and iv) outline attributes of the experiments in order to classify the context where findings can be grouped. These challenges indicate some paths to be followed by the area in order to systematize the use of code smell in the practice of the software development. Despite difficulties, we believe that this is possible and our thesis contributes for this journey. / Contexto: Code smell ´e um termo comumente utilizado para descrever potenciais problemas em projetos de software orientados a objetos. A teoria relacionada a code smells, inicialmente apresentada nos anos noventa, tem foco na caracteriza¸c˜ao de diferentes tipos de smells e nas estrat´egias para sua detec¸c˜ao e remo¸c˜ao. Desde ent˜ao, estudos emp´ıricos tˆem avaliado o impacto da ado¸c˜ao do conceito de code smell no desenvolvimento de software, ou seja, o “efeito code smell”. Os resultados destes estudos tˆem apresentado inconsistˆencias com rela¸c˜ao aos efeitos propostos pela teoria. As causas deste fenˆomeno n˜ao s˜ao bem compreendidas. Objetivo: Melhorar a compreens˜ao sobre o efeito code smell, identificando problemas que tˆem dificultado uso do conceito no desenvolvimento de software. Mais especificamente, nos concentramos no papel humano na detec¸c˜ao de smells. O fator humano ´e uma vari´avel pouco considerada pela teoria, mas afeta significativamente os resultados dos estudos emp´ıricos sobre o tema. M´etodo: N´os exploramos o problema de forma emp´ırica, a partir de duas perspectivas. Primeiro, n´os sintetizamos o conhecimento relacionado ao efeito code smell a partir de um conjunto de estudos prim´arios existente na literatura. Para isso, n´os realizamos uma revis˜ao sistem´atica, com base no m´etodo de s´ıntese tem´atica. Segundo, n´os propusemos a investiga¸c˜ao de fatores que afetam a percep¸c˜ao humana sobre smells. Neste caso, n´os realizamos uma fam´ılia de experimentos controlados, investigando um extensivo n´umero de fatores que afetam a percep¸c˜ao humana sobre smells. Os fatores s˜ao: o uso de ferramentas de suporte `a compreens˜ao do projeto de software; a experiˆencia; o conhecimento te´orico sobre code smells e o treinamento dos desenvolvedores; e o tamanho do software. A partir da s´ıntese tem´atica e da fam´ılia de experimentos, n´os identificamos alguns desafios para a ´area, apresentandoos como uma agenda de pesquisa. Resultados: N´os percebemos que a avalia¸c˜ao humana de smells n˜ao ´e confi´avel. Os estudos indicam que o grau de concordˆancia relacionado `a avalia¸c˜ao humana ´e baixo. Al´em disso, os estudos mostram que atributos demogr´aficos, como experiˆencia do desenvolvedor, afetam o grau de concordˆancia na detec¸c˜ao de smells. Tamb´em conclu´ımos que n˜ao h´a evidˆencias que indiquem o uso do conceito de code smells como ferramenta para a avalia¸c˜ao da qualidade dos projetos de software. Estas evidˆencias s˜ao as inconsistˆencias nos resultados correlacionando os smells e atributos de software, como mudan¸cas no c´odigo. Em alguns casos, os estudos concordam que os smells n˜ao tem correla¸c˜ao com certos atributos. Isso ocorre, por exemplo, com estudos correlacionando smells e esfor¸co na manuten¸c˜ao de software. Conclus˜ao: Esta tese evidencia uma lacuna existente entre a teoria e os estudos emp´ıricos relacionados ao efeito code smell. Nossas evidˆencias apontam o baixo n´umero de estudos abordando o papel humano na detec¸c˜ao de smells como principal causa desta lacuna. Pesquisas na ´area devem se concentrar em entender este aspecto. Este n˜ao parece ser o caminho seguido pela ´area, que tem se concentrado principalmente no desenvolvimento de ferramentas de suporte, como ferramentas para detec¸c˜ao autom´atica e remo¸c˜ao de smells. Para auxiliar neste sentido, n´os propomos uma agenda de pesquisa indicando pontos importantes a serem considerados: i) investiga¸c˜ao da natureza dos smells, agrupando-os de acordo com suas caracter´ısticas; ii) explora¸c˜ao de fatores humanos afetando a detec¸c˜ao de smells e seus inter-relacionamentos; iii) explora¸c˜ao de aspectos cognitivos afetando a percep¸c˜ao humana de smells; e iv) identifica¸c˜ao de atributos relacionados aos estudos emp´ıricos de forma a delinear o contexto onde resultados podem ser agrupados. Estes desafios indicam alguns caminhos que a ´area pode seguir para sistematizar o uso do conceito de code smell no desenvolvimento de software. Apesar das dificuldades, n´os acreditamos que isso ´e poss´ıvel e nossa tese visa a contribuir neste sentido.

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

Code smells are defined as poor implementation and coding practices, and as a result decrease the overall quality of a source code. A number of code smell detection tools are available to automatically detect poor implementation choices, i.e., code smells. The detection of code smells is essential in order to improve the quality of the source code. This report aims to evaluate the accuracy and quality of seven different open-source code smell detection tools, with the purpose of establishing their level of trustworthiness.To assess the trustworthiness of a tool, we utilize a controlled experiment in which several versions of each tool are scrutinized using the most recent version of the same tool. In particular, we wanted to verify to what extent the code smell detection tools that reveal code smells in other systems, contain smells themselves. We further study the evolution of code smells in the tools in terms of number, types of code smells and code smell density.

Background. Machine learning (ML) has rapidly grown in popularity, becoming a vital part of many industries. This swift expansion has brought about new challenges to technical debt, maintainability and the general software quality of ML systems. With ML applications becoming more prevalent, there is an emerging need for extensive research to keep up with the pace of developments. Currently, the research on code smells in ML applications is limited and there is a lack of tools and studies that address these issues in-depth. This gap in the research highlights the necessity for a focused investigation into the validity of ML-specific code smells in ML applications, setting the stage for this research study. Objectives. Addressing the limited research on ML-specific code smells within Python-based ML applications. To achieve this, the study begins with the identification of these ML-specific code smells. Once recognized, the next objective is to choose suitable methods and tools to design and develop a static code analysis tool based on code smell criteria. After development, an empirical evaluation will assess both the tool’s efficacy and performance. Additionally, feedback from industry professionals will be sought to measure the tool’s feasibility and usefulness. Methods. This research employed Design Science Methodology. In the problem identification phase, a literature review was conducted to identify ML-specific code smells. In solution design, a secondary literature review and consultations with experts were performed to select methods and tools for implementing the tool. Additionally, 160 open-source ML applications were sourced from GitHub. The tool was empirically tested against these applications, with a focus on assessing its performance and efficacy. Furthermore, using the static validation method, feedback on the tool’s usefulness was gathered through an expert survey, which involved 15 ML professionals from Ericsson. Results. The study introduced MLpylint, a tool designed to identify 20 ML-specific code smells in Python-based ML applications. MLpylint effectively analyzed 160ML applications within 36 minutes, identifying in total 5380 code smells, although, highlighting the need for further refinements to each code smell checker to accurately identify specific patterns. In the expert survey, 15 ML professionals from Ericsson acknowledged the tool’s usefulness, user-friendliness and efficiency. However, they also indicated room for improvement in fine-tuning the tool to avoid ambiguous smells. Conclusions. Current studies on ML-specific code smells are limited, with few tools addressing them. The development and evaluation of MLpylint is a significant advancement in the ML software quality domain, enhancing reliability and reducing associated technical debt in ML applications. As the industry integrates such tools, it’s vital they evolve to detect code smells from new ML libraries. Aiding developers in upholding superior software quality but also promoting further research in the ML software quality domain.

[pt] Anomalias de código são estruturas anômalas de código que podem indicar problemas de manutenção. A identificação de anomalias é necessária para revelar elementos de código mal estruturados, tais como classes e métodos. Porém, a identificação individual de anomalias, realizada por um único desenvolvedor, pode ser ineficaz. Estudos reportam limitações da identificação individual de anomalias. Por exemplo, a identificação de anomalias requer uma compreensão profunda de múltiplos elementos de um programa, e cada elemento é melhor entendido por um desenvolvedor diferente. Logo, um desenvolvedor isolado frequentemente tem dificuldades para encontrar, confirmar e refutar uma suspeita de anomalia. Identificação colaborativa de anomalias, que é realizada em conjunto por dois ou mais colaboradores, tem o potencial para resolver esse problema. Porém, há pouca evidência empírica sobre a eficácia da identificação colaborativa de anomalias. Nesta tese, nós conduzimos estudos empíricos para entender a eficácia da identificação individual e colaborativa de anomalias. Computamos e comparamos a eficácia de colaboradores e desenvolvedores isolados com base no número de anomalias identificadas corretamente. Conduzimos tais estudos em empresas e laboratórios de pesquisa, totalizando 67 desenvolvedores, incluindo desenvolvedores novatos e experientes. Também definimos alguns fatores de influência sobre a eficácia da identificação colaborativa de anomalias, tais como a granularidade da anomalia. Revelamos e caracterizamos algumas atividades colaborativas que melhoram a eficácia dos desenvolvedores na identificação de anomalias. Finalmente, identificamos oportunidades para melhorar certas atividades colaborativas. Nossos resultados sugerem que colaboradores são significativamente mais eficazes que desenvolvedores isolados, tanto desevolvedores novatos quanto experientes. Concluímos que colaborar é vantajoso para melhorar a identificação de uma vasta gama de tipos de anomalia. / [en] Code smells are anomalous code structures which often indicate maintenance problems in software systems. The identification of code smells is required to reveal code elements, such as classes and methods, that are poorly structured. Some examples of code smell types perceived as critical by developers include God Classes and Feature Envy. However, the individual smell identification, which is performed by a single developer, may be ineffective. Several studies have reported limitations of individual smell identification. For instance, the smell identification usually requires an indepth understanding of multiple elements scattered in a program, and each of these elements is better understood by a different developer. As a consequence, a single developer often struggles and to find to confirm or refute a code smell suspect. Collaborative smell identification, which is performed together by two or more collaborators, has the potential to address this problem. However, there is little empirical evidence on the effectiveness of collaborative smell identification. In this thesis, we addressed the aforementioned limitations as follows. First, we conducted empirical studies aimed at understanding the effectiveness of both collaborative and individual smell identification. We computed and compared the effectiveness of collaborators and single developers based on the number of correctly identified code smells. We conducted these studies in both industry’s companies and research laboratories with 67 developers, including novice and professional developers. Second, we defined some influential factors on the effectiveness of collaborative smell identification, such as the smell granularity. Third, we revealed and characterized some collaborative activities which improve the developers effectiveness for identifying code smells. Fourth, we also characterized opportunities for further improving the effectiveness of certain collaborative activities. Our results suggest that collaborators are more effective than single developers in: (i) both professional and academic settings, and (ii) identifying a wide range of code smell types.

[pt] Anomalias de código podem sinalizar a degradação da arquitetura de software. No entanto, a identificação de anomalias de código arquiteturalmente relevantes (ou seja, aquelas que implicam em deficiências arquiteturais) é particularmente difícil devido: (i) a falta de compreensão sobre a relação existente entre anomalias de código e degradação arquitetural, (ii) ao fato do processo de detecção de anomalias ter como foco somente o código fonte, sem considerar como ele se relaciona com sua arquitetura, e (iii) a falta de conhecimento sobre a confiabilidade das técnicas de detecção em revelar anomalias de código que são arquiteturalmente relevantes. Esta tese apresenta técnicas para identificar anomalias de código que são arquiteturalmente relevantes. Métricas sensíveis à arquitetura e estratégias de detecção foram definidas para superar as limitações das técnicas de detecção convencionais. Estas métricas e estratégias aproveitam rastros que podem ser estabelecidos entre as visões arquiteturais e a implementação dos sistemas. A tese também documenta padrões de anomalias de código (ou seja, relações recorrentes de anomalias) que estão relacionados com problemas arquiteturais. Uma ferramenta, chamada de SCOOP, foi desenvolvida para coletar as métricas sensíveis à arquitetura, aplicar as novas estratégias de detecção, e identificar os padrões de anomalias de código. Usando esta ferramenta, a técnica proposta foi avaliada em uma série de estudos empíricos, comparando sua acurácia com técnicas convencionais de detecção durante o processo de identificação de anomalias de código que são arquiteturalmente relevantes. / [en] Code anomalies can signal software architecture degradation. However, the identification of architecturally-relevant code anomalies (i.e. code anomalies that strongly imply architectural deficiencies) is particularly challenging due to: (i) lack of understanding about the relationship between code anomalies and architectural degradation, (ii) the focus on source code anomaly detection without considering how it relates to the software architecture, and (iii) lack of knowledge about how reliable these detection techniques are when revealing architecturally-relevant code anomalies. This thesis presents techniques for identifying architecturally-relevant code anomalies. Architecture-sensitive metrics and detection strategies were defined to overcome the limitations of conventional detection strategies. These metrics and strategies leverage traces that can be established between architectural views and system implementation. The thesis also documents code anomaly patterns (i.e. recurring anomaly relationships) that are strongly related to architectural problems. A tool, called SCOOP, was developed to collect the architecture-sensitive metrics, apply the new detection strategies, and identify the documented code anomaly patterns. Using this tool, we evaluated our technique in a series of empirical studies, comparing its accuracy with that of conventional detection techniques when identifying architecturally-relevant code anomalies.

[pt] Problemas de design decorrem de violações de princípios de design em um sistema de software. Tais problemas podem prejudicar a manutenção de sistemas e, logo, devem ser identificados e eliminados sempre que possível. Porém, identificar problemas de design não é trivial. Isso pois a documentação de design desses sistemas é em geral obsoleta ou inexistente. Assim, o desenvolvedor de um sistema tende a analisar o código-fonte em busca de problemas de design. Estudos sugerem anomalias de código-fonte como indicadores úteis desses problemas. Porém, outros estudos recentes mostram que uma única anomalia não é indicador suficiente. De fato, em torno de 80 por cento dos problemas de design estão associadas com múltiplas anomalias. Estas inter-relacionam-se na forma de aglomerações de anomalias. Embora as aglomerações de anomalias possam ajudar o desenvolvedor a identificar problemas de design, certas aglomerações contêm muitas anomalias. Isso então dificulta o raciocínio sobre a existência de um problema de design. Além disso, mesmo as propostas mais recentes de abordagens para a visualização de aglomerações de anomalias provêm suporte bastante limitado à identificação de problemas de design. Essa limitação é evidente quando um problema de design afeta múltiplos elementos na implementação de um sistema. Esta dissertação objetiva tratar essa limitação ao propor uma abordagem inovadora para a visualização de aglomerações de anomalias. Tal abordagem baseia-se em evidências coletadas a partir de vários experimentos propostos e conduzidos por nós. Contamos com a participação de desenvolvedores da academia e da indústria em cada experimento. Nossos resultados de estudo sugerem que vários desenvolvedores podem utilizar nossa abordagem de visualização para identificar de forma precisa problemas de design, especialmente aqueles que afetam múltiplos elementos de programa. Nossos resultados também apontam melhorias necessárias à abordagem com base na percepção dos desenvolvedores. / [en] Design problems are characterized by violations of design principles affecting a software system. Because they often hinder the software maintenance, developers should identify and eliminate design problems whenever possible. Nevertheless, identifying design problems is far from trivial. Due to outdated and scarce design documentation, developers not rarely have to analyze the source code for identifying these problems. Past studies suggest that code smells are useful hints of design problems. However, recent studies show that a single code smell might not suffice to reveal a design problem. That is, around 80 percent of design problems are realized by multiple code smells, which interrelate in the so-called smell agglomerations. Thus, developers can explore each smell agglomeration to identify a design problem in the source code. However, certain smell agglomerations are formed by several code smells, which makes it hard reasoning about the existence of a design problem. Visualization approaches have been proposed to represent smell agglomerations and guide developers in identifying design problems. However, those approaches provide a very limited support to the identification of specific design problems, especially the ones affecting multiple design elements. This dissertation aims to address this limitation by proposing a novel approach for the visualization of smell agglomerations. We rely on evidence collected from multiple empirical studies to design our approach. We evaluate our approach with developers from both academy and industry. Our results suggest that various developers could use our visualization approach to accurately identify design problems, in particular those affecting multiple program elements. Our results also point out to different ways for improving our visualization approach based on the developers perceptions.

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

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.