Submitted by Renata Lopes (renatasil82@gmail.com) on 2017-10-21T01:04:22Z No. of bitstreams: 1 claudioaugustosilveiralelis.pdf: 7232359 bytes, checksum: 731c10b688562fad8855da41890a7f97 (MD5) / Approved for entry into archive by Adriana Oliveira (adriana.oliveira@ufjf.edu.br) on 2017-10-21T13:13:19Z (GMT) No. of bitstreams: 1 claudioaugustosilveiralelis.pdf: 7232359 bytes, checksum: 731c10b688562fad8855da41890a7f97 (MD5) / Made available in DSpace on 2017-10-21T13:13:19Z (GMT). No. of bitstreams: 1 claudioaugustosilveiralelis.pdf: 7232359 bytes, checksum: 731c10b688562fad8855da41890a7f97 (MD5) Previous issue date: 2017-08-30 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / A importância dos softwares nas organizações é crescente. No entanto, para manter seu valor, o software deve ser alterado e atualizado. A manutenção de software depende da alocação de recursos humanos para o cumprimento das atividades de alteração definidas. Entretanto, em um cenário distribuído no qual a colaboração é fundamental para o bom funcionamento das atividades, torna-se uma tarefa não trivial designar desenvolvedores para as atividades de manutenção. Neste contexto, a reputação se torna um elemento chave, afetando os elementos de colaboração, tais como: a coordenação, a cooperação, e a comunicação. Portanto, o acompanhamento da evolução da reputação é importante para promover a colaboração nas atividades de manutenção. A teoria de Dinâmica de Sistemas pode ser aplicada no acompanhamento da evolução da reputação. Através dos dados obtidos, é possível compreender o passado, estabelecer o que ocorre no presente e projetar o comportamento futuro da reputação. Diante disso, este trabalho apresenta um modelo para cálculo da reputação dos desenvolvedores de software, apoiado por técnicas de Dinâmica de Sistemas, o qual permite simular como a reputação se comporta ao longo do tempo. Este modelo serviu de base para a construção de uma infraestrutura para informações de reputação dinâmica, cujo objetivo é possibilitar o gerenciamento e acompanhamento de informações de reputação dos desenvolvedores geograficamente distribuídos de forma a apoiar a alocação desses desenvolvedores às tarefas de manutenção. Além disso, oferece elementos de visualização e colaboração, em um ambiente integrado às atividades de manutenção de software. Uma prova de conceito e um experimento realizados com dados reais de uma empresa são apresentados com o intuito de identificar a viabilidade e aderência do modelo proposto, bem como dos demais recursos oferecidos pela infraestrutura. / The importance of software in organizations is growing. However, to maintain its value, the software must be changed and updated. Software maintenance depends on the allocation of human resources to fulfill defined change activities. However, in a distributed scenario in which collaboration is critical to the well running of activities, designate developers for maintenance activities becomes a non-trivial task. In this context, reputation becomes a key element, affecting elements of collaboration, such as: coordination, cooperation, and communication. Therefore, tracking reputation evolution is important to promote collaboration in maintenance activities. The theory of System Dynamics can be applied in monitoring the evolution of reputation. Through the data obtained, it is possible to understand the past, establish what occurs in the present, and project future reputation behavior. Therefore, this work presents a model for calculating the reputation of software developers, supported by System Dynamics techniques, which allows simulating how reputation behaves over time. This model served as the basis for building an infrastructure for dynamic reputation information, which aims to enable the management and tracking reputation information of geographically distributed developers to support the allocation of these developers to maintenance tasks. In addition, it provides visualization and collaboration elements in an integrated environment for software maintenance activities. A proof of concept and an experiment made with real data of a company are presented with the intention of identifying the feasibility and adherence of the proposed model, as well as of the other resources offered by the infrastructure.

Abstract To gain competitive advantage and thrive in the market, companies have introduced Kanban in software development. Kanban has been used in the manufacturing industry for over six decades. In the software engineering domain, Kanban was introduced in 2004 to increase flexibility in coping with dynamic requirements, bring visibility to workflow and related tasks, improve communication, and promote the pull system. However, the existing scientific literature lacks empirical evidence of the use of Kanban in software companies. This doctoral thesis aims to improve the understanding of the use of Kanban in software engineering. The research was performed in two phases: 1) analysis of scientific literature on Kanban in software engineering and industrial engineering and 2) investigation of Kanban implementation trends in software companies. The data was collected through systematic literature reviews, survey and semi-structured interviews. The results were synthesized to draw conclusions and outline implications for research and practice. The results indicate growing interest in the use of Kanban in software companies. The findings suggest that Kanban is applicable to software development, software maintenance, and portfolio management in software companies. Kanban brings visibility to task and offering status, limits work in progress at any given time gives people greater control over their work and limit task switching. Although Kanban offers several benefits, as reported in this dissertation, the findings show that software companies find it challenging to implement Kanban incrementally. / Tiivistelmä Ohjelmistoteollisuudessa Kanbanin käyttö on yleistynyt vuodesta 2004 alkaen. Sillä pyritään tuomaan joustavuutta muuttuvien vaatimusten hallintaan, tuomaan näkyvyyttä työnkulkuun ja toisiinsa liittyviin tehtäviin, parantamaan kommunikaatiota sekä edistämään imuohjauksen hyödyntämistä. Kanbania on käytetty valmistavassa teollisuudessa jo yli kuuden vuosikymmenen ajan. Olemassa olevassa tieteellisessä kirjallisuudessa on kuitenkin esitetty hyvin vähän empiirisiä tutkimustuloksia Kanbanin käytöstä ohjelmistoyrityksissä. Väitöskirjan tavoitteena on parantaa ymmärrystä Kanbanin käytöstä ohjelmistotuotannossa. Tutkimus toteutettiin kahdessa vaiheessa: 1) Kirjallisuusanalyysi Kanbanin käytöstä ohjelmistotuotannossa ja tuotantotekniikassa ja 2) Empiirinen tutkimus Kanbanin käyttöönoton trendeistä ohjelmistoyrityksissä. Tutkimusaineisto kerättiin systemaattisten kirjallisuuskatsausten, kyselytutkimuksen ja puolistrukturoitujen teemahaastattelujen kautta. Tutkimustulosten synteesin pohjalta tehtiin johtopäätöksiä Kanbanin käytöstä ohjelmistotuotannossa sekä niiden merkityksestä alan tutkimukselle ja Kanbanin käytölle yrityksissä. Tutkimuksen tulokset osoittavat kasvavaa kiinnostusta Kanbanin käyttöä kohtaan ohjelmistoyrityksissä. Tulosten perusteella Kanban soveltuu käytettäväksi ohjelmistokehityksessä, ohjelmistojen ylläpidossa sekä tuoteportfolion hallinnassa. Kanban tuo näkyvyyttä ohjelmistokehitykseen, niin meneillään olevien tehtävien kuin portfoliotarjoaman osalta. Se myös auttaa rajoittamaan työtehtävien ruuhkautumista ja antaa kehittäjille paremman tavan hallita työtään rajoittamalla työtehtävien vaihtoa. Vaikka Kanbanin käytöllä on mahdollista saavuttaa väitöskirjatutkimuksessa esitettyjä hyötyjä, tulokset osoittavat, että ohjelmistoyrityksillä on haasteita Kanbanin inkrementaalisessa käyttöönotossa.

This report evaluates the team-structure of three software maintenance teams in order to decide their level of featureness (a term that defines to what extent a team has the quality (the set of characteristics) of being a feature team). Simulations of changes that are expressed as beneficial in an agile environment and that could increase the teams‘ level of featureness within the team structure are performed. The results show that each team‘s level of featureness is affected differently by each change. Partly, this underlines the importance of understanding the current team-structure before implementing changes that aim to increase the level of featureness. And secondly, within the scope of the study, the change where a user expert is declared a team member is concluded as the change that increases the teams‘ level of featureness the most. Based on the results the report also concludes that it is essential to implement changes that affect different, which in combination can increase the level of featureness.

Masters of Science / Coders of databases repeatedly face the problem of checking their Structured Query Language (SQL) code. Instructors face the difficulty of checking student projects and lab assignments in database courses. We collect and categorize common MySQL programming errors into three groups: data definition errors, data manipulation errors, and transaction control errors. We build these into a comprehensive list of MySQL errors, which novices are inclined make during database programming. We collected our list of common MySQL errors both from the technical literature and directly by noting errors made in assignments handed in by students. In the results section of this research, we check and summarize occurrences of these errors based on three characteristics as semantics, syntax, and logic. These data form the basis of a future static MySQL checker that will eventually assist database coders to correct their code automatically. These errors also form a useful checklist to guide students away from the mistakes that they are prone to make.

Les systèmes logiciels sont devenus de plus en plus répondus et importants dans notre société. Ainsi, il y a un besoin constant de logiciels de haute qualité. Pour améliorer la qualité de logiciels, l’une des techniques les plus utilisées est le refactoring qui sert à améliorer la structure d'un programme tout en préservant son comportement externe. Le refactoring promet, s'il est appliqué convenablement, à améliorer la compréhensibilité, la maintenabilité et l'extensibilité du logiciel tout en améliorant la productivité des programmeurs. En général, le refactoring pourra s’appliquer au niveau de spécification, conception ou code. Cette thèse porte sur l'automatisation de processus de recommandation de refactoring, au niveau code, s’appliquant en deux étapes principales: 1) la détection des fragments de code qui devraient être améliorés (e.g., les défauts de conception), et 2) l'identification des solutions de refactoring à appliquer. Pour la première étape, nous traduisons des régularités qui peuvent être trouvés dans des exemples de défauts de conception. Nous utilisons un algorithme génétique pour générer automatiquement des règles de détection à partir des exemples de défauts. Pour la deuxième étape, nous introduisons une approche se basant sur une recherche heuristique. Le processus consiste à trouver la séquence optimale d'opérations de refactoring permettant d'améliorer la qualité du logiciel en minimisant le nombre de défauts tout en priorisant les instances les plus critiques. De plus, nous explorons d'autres objectifs à optimiser: le nombre de changements requis pour appliquer la solution de refactoring, la préservation de la sémantique, et la consistance avec l’historique de changements. Ainsi, réduire le nombre de changements permets de garder autant que possible avec la conception initiale. La préservation de la sémantique assure que le programme restructuré est sémantiquement cohérent. De plus, nous utilisons l'historique de changement pour suggérer de nouveaux refactorings dans des contextes similaires. En outre, nous introduisons une approche multi-objective pour améliorer les attributs de qualité du logiciel (la flexibilité, la maintenabilité, etc.), fixer les « mauvaises » pratiques de conception (défauts de conception), tout en introduisant les « bonnes » pratiques de conception (patrons de conception). / Software systems have become prevalent and important in our society. There is a constant need for high-quality software. Hence, to improve software quality, one of the most-used techniques is the refactoring which improves design structure while preserving the external behavior. Refactoring has promised, if applied well, to improve software readability, maintainability and extendibility while increasing the speed at which programmers can write and maintain their code. In general, refactoring can be performed in various levels such as the requirement, design, or code level. In this thesis, we mainly focus on the source code level where automated refactoring recommendation can be performed through two main steps: 1) detection of code fragments that need to be improved/fixed (e.g., code-smells), and 2) identification of refactoring solutions to achieve this goal. For the code-smells identification step, we translate regularities that can be found in such code-smell examples into detection rules. To this end, we use genetic programming to automatically generate detection rules from examples of code-smells. For the refactoring identification step, a search-based approach is used. The process aims at finding the optimal sequence of refactoring operations that improve software quality by minimizing the number of detected code-smells while prioritizing the most critical ones. In addition, we explore other objectives to optimize using a multi-objective approach: the code changes needed to apply refactorings, semantics preservation, and the consistency with development change history. Hence, reducing code changes allows us to keep as much as possible the initial design. On the other hand, semantics preservation insures that the refactored program is semantically coherent, and that it models correctly the domain-semantics. Indeed, we use knowledge from historical code change to suggest new refactorings in similar contexts. Furthermore, we introduce a novel multi-objective approach to improve software quality attributes (i.e., flexibility, maintainability, etc.), fix “bad” design practices (i.e., code-smells) while promoting “good” design practices (i.e., design patterns).

Bons códigos importam, mas como saber quando a qualidade está baixa? Maus cheiros de código, ou anomalias, auxiliam desenvolvedores na identificação de trechos de código problemáticos, porém a maioria dos maus cheiros catalogados são voltados para práticas e tecnologias tradicionais, criadas entre as décadas de 70 a 90, como orientação a objetos e Java. Ainda há dúvidas sobre maus cheiros em tecnologias que surgiram na última década, como o Android, principal plataforma móvel em 2017 com mais de 86% de participação de mercado. Alguns pesquisadores derivaram maus cheiros Android relacionados à eficiência e à usabilidade. Outros notaram que maus cheiros específicos ao Android são muito mais frequentes nos aplicativos do que maus cheiros tradicionais. Diversas pesquisas concluíram que os componentes Android mais afetados por maus cheiros tradicionais são Activities e Adapters, que pertencem à camada de apresentação. Notou-se também que em alguns aplicativos, códigos da camada de apresentação representam a maior parte do código do projeto. Vale ressaltar que a camada de apresentação Android também é composta por arquivos XML, chamados de recursos, usados na construção da interface do usuário (User Interface - UI), porém nenhuma das pesquisas citadas os considerou em suas análises. Nesta dissertação, investigamos a existência de maus cheiros relacionados à camada de apresentação Android considerando inclusive os recursos. Fizemos isso através de dois questionários e um experimento de código online, totalizando a participação de 316 desenvolvedores. Nossos resultados mostram a existência de uma percepção comum entre desenvolvedores sobre más práticas no desenvolvimento da camada de apresentação Android. Nossas principais contribuições são um catálogo com 20 maus cheiros da camada de apresentação Android e uma análise estatística da percepção de desenvolvedores sobre os 7 principais maus cheiros catalogados. Nossas contribuições servirão a pesquisadores como ponto de partida para a definição de heurísticas e implementação de ferramentas automatizadas e a desenvolvedores como auxílio na identificação de códigos problemáticos, ainda que de forma manual. / We are aware that good code matters, but how to know when quality is low? Code smells, or anomalies, help us identify problematic code snippets, but most of the code smells cataloged are based on traditional practices and technologies, created from the 70s through the 90s, such as object oriented programming and Java. There are still doubts about code smells in technologies that have emerged in the last decade, such as Android, the main mobile platform in 2017 with more than 86% market share. Some researchers have defined code smells related to Android efficiency and usability. Other research concludes that the components most affected by traditional code smells are related to the front-end components, such as Activities and Adapters. Also noticed in some applications, front-end code represent the larger part of the projects code. It is worth mentioning that the Android presentation layer is also composed of XML files, called resources, used to build the user interface (UI), but none of the cited research considered them in their analyzes. In this dissertation, we investigate the existence of code smells related to the Android front-end, including application resources. We performed two online surveys and one online code experiment, summing 316 developers. Our results show that there is a common perception among Android developers about bad practices on Android front-end. Our main contributions are a catalog of 20 code smells related to the Android front-end and a statistical analysis of the perceptions of developers about the 7 main code smells cataloged. Our contributions will provide to researchers a starting point for the definition of heuristics and implementation of automated tools and to developers as an aid in identifying problematic codes.

Bons códigos importam, mas como saber quando a qualidade está baixa? Maus cheiros de código, ou anomalias, auxiliam desenvolvedores na identificação de trechos de código problemáticos, porém a maioria dos maus cheiros catalogados são voltados para práticas e tecnologias tradicionais, criadas entre as décadas de 70 a 90, como orientação a objetos e Java. Ainda há dúvidas sobre maus cheiros em tecnologias que surgiram na última década, como o Android, principal plataforma móvel em 2017 com mais de 86% de participação de mercado. Alguns pesquisadores derivaram maus cheiros Android relacionados à eficiência e à usabilidade. Outros notaram que maus cheiros específicos ao Android são muito mais frequentes nos aplicativos do que maus cheiros tradicionais. Diversas pesquisas concluíram que os componentes Android mais afetados por maus cheiros tradicionais são Activities e Adapters, que pertencem à camada de apresentação. Notou-se também que em alguns aplicativos, códigos da camada de apresentação representam a maior parte do código do projeto. Vale ressaltar que a camada de apresentação Android também é composta por arquivos XML, chamados de recursos, usados na construção da interface do usuário (User Interface - UI), porém nenhuma das pesquisas citadas os considerou em suas análises. Nesta dissertação, investigamos a existência de maus cheiros relacionados à camada de apresentação Android considerando inclusive os recursos. Fizemos isso através de dois questionários e um experimento de código online, totalizando a participação de 316 desenvolvedores. Nossos resultados mostram a existência de uma percepção comum entre desenvolvedores sobre más práticas no desenvolvimento da camada de apresentação Android. Nossas principais contribuições são um catálogo com 20 maus cheiros da camada de apresentação Android e uma análise estatística da percepção de desenvolvedores sobre os 7 principais maus cheiros catalogados. Nossas contribuições servirão a pesquisadores como ponto de partida para a definição de heurísticas e implementação de ferramentas automatizadas e a desenvolvedores como auxílio na identificação de códigos problemáticos, ainda que de forma manual. / We are aware that good code matters, but how to know when quality is low? Code smells, or anomalies, help us identify problematic code snippets, but most of the code smells cataloged are based on traditional practices and technologies, created from the 70s through the 90s, such as object oriented programming and Java. There are still doubts about code smells in technologies that have emerged in the last decade, such as Android, the main mobile platform in 2017 with more than 86% market share. Some researchers have defined code smells related to Android efficiency and usability. Other research concludes that the components most affected by traditional code smells are related to the front-end components, such as Activities and Adapters. Also noticed in some applications, front-end code represent the larger part of the projects code. It is worth mentioning that the Android presentation layer is also composed of XML files, called resources, used to build the user interface (UI), but none of the cited research considered them in their analyzes. In this dissertation, we investigate the existence of code smells related to the Android front-end, including application resources. We performed two online surveys and one online code experiment, summing 316 developers. Our results show that there is a common perception among Android developers about bad practices on Android front-end. Our main contributions are a catalog of 20 code smells related to the Android front-end and a statistical analysis of the perceptions of developers about the 7 main code smells cataloged. Our contributions will provide to researchers a starting point for the definition of heuristics and implementation of automated tools and to developers as an aid in identifying problematic codes.

Les logiciels dépendent de bibliothèques tierces pour réduire les coûts liés à leur développement et à leur maintenance. Elles proposent un ensemble de fonctionnalités robustes dont les développeurs peuvent tirer parti depuis une interface de programmation. Cependant, cette forte dépendance entre un logiciel et ses bibliothèques oblige les développeurs à reconsidérer leur rôle lorsque le logiciel évolue. Dans cette thèse, nous identifions plusieurs problématiques impliquant les bibliothèques tierces dans un contexte de maintenance logicielle. Plus particulièrement, une bibliothèque peut ne plus répondre aux besoins d’un logiciel et doit être remplacée par une nouvelle.Nous nommons cette opération une migration de bibliothèque.Nous soulevons dans ce contexte trois points qui caractérisent les difficultés rencontrées par les développeurs. Vers quelle bibliothèque migrer ? Comment appliquer la migration ? Avec l’aide de quels développeurs ? Cette thèse discute de solutions et apporte des contributions autour de ces problèmes. Nous présentons plusieurs approches et les évaluons lors de différents cas d’étude. L’analyse de l’évolution logicielle sera notre support de travail, dont la méthodologie est basée sur l’observation des changements de logiciels. Nous décrivons les limites actuelles de nos contribu-tions et ouvrons des perspectives futures pour enrichir l’état de l’art dans ce domaine / Software depend on third-party libraries to reduce development and maintenance costs. Developers have access to robust functionalities through an application programming interface designed by these libraries. However, due to the strong relationship with these libraries, developers have to reconsider their position when the software evolves. In this thesis, we identify several re-search problems involving these third-party libraries in a context of software maintenance. More specifically, a library may not satisfy the software new requirements and has to be replaced by anew one. We call this operation a library migration.We leverage three points that characterize the impediments met by developers in this situation.To which library should they migrate ? How to migrate their software ? Who can help them in this case ? This thesis suggests answers and exposes several contributions to these problems. We define three approaches that are evaluated through several case studies. To achieve this work, weuse a methodology based on software evolution analysis to observe and understand how software change. We describe numerous perspectives to overcome the current limitations of our solutions.

The problems of software debugging and system reliability/availability are among the most challenging problems the computing industry is facing today, with direct impact on the development and operating costs of computing systems. A promising debugging technique that assists programmers identify and fix the causes of software bugs a lot more efficiently is bidirectional debugging, which enables the user to execute the program in "reverse", and a typical method used to recover a system after a fault is backwards error recovery, which restores the system to the last error-free state. Both reverse execution and backwards error recovery are enabled by creating memory checkpoints, which are used to restore the program/system to a prior point in time and re-execute until the point of interest. The checkpointing frequency is the primary factor that affects both the latency of reverse execution and the recovery time of the system; more frequent checkpoints reduce the necessary re-execution time. Frequent creation of checkpoints poses performance challenges, because of the increased number of memory reads and writes necessary for copying the modified system/program memory, and also because of software interventions, additional synchronization and I/O, etc., needed for creating a checkpoint. In this thesis I examine a number of different hardware accelerators, whose role is to create frequent memory checkpoints in the background, at minimal performance overheads. For the purpose of reverse execution, I propose the HARE and Euripus hardware checkpoint accelerators. HARE and Euripus create different types of checkpoints, and employ different methods for keeping track of the modified memory. As a result, HARE and Euripus have different hardware costs and provide different functionality which directly affects the latency of reverse execution. For improving the availability of the system, I propose the Kyma hardware accelerator. Kyma enables simultaneous creation of checkpoints at different frequencies, which allows the system to recover from multiple types of errors and tolerate variable error-detection latencies. The Kyma and Euripus hardware engines have similar architectures, but the functionality of the Kyma engine is optimized for further reducing the performance overheads and improving the reliability of the system. The functionality of the Kyma and Euripus engines can be combined into a unified accelerator that can serve the needs of both bidirectional debugging and system recovery.

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