Eduardo Figueiredo

Design Pattern Detection (DPD) tools are useful to support to the comprehension and maintenance of software systems. Although several DPD tools have been introduced over the years, they typically focus on a limited set of design patterns and programming languages. This paper aims to investigate (i) the reasons that motivate DPD tool designers to target specific design patterns and programming languages, and (ii) how potential users perceive the usefulness of DPD tools in practical software development scenarios. We conducted two online surveys. For the first survey, we reached out to designers of 42 DPD tools selected from a systematic literature review to obtain their perspectives on design decisions about pattern and language coverage, receiving 22% of such responses. For the second survey, we recruited 28 student and senior developers to help us understand their expectations, perceived benefits, and concerns related to the use of DPD tools. Within our sample, the findings suggest that participating tool designers often prioritize design patterns whose internal structure facilitates automated detection, while language support is frequently motivated by popularity and expected demand. From the perspective of tool users, DPD tools are expected to support development activities, such as program comprehension and software quality improvement. Unfortunately, usability difficulties, limited accuracy, and insufficient documentation often discourage them from adopting a tool. The responses suggest that some design decisions reported by participating DPD tool designers are aligned with practical and industrial considerations. However, the recurring lack of adequate documentation and usability support is a major barrier to wider usage. Taken as indicative evidence, these results suggest that future DPD tools should better balance detection capabilities and usability concerns, especially to meet the need of less experienced developers. Given the limited number of tool-designer respondents, conclusions about design rationale should be interpreted as indicative rather than representative of all DPD tool designers.

JavaScript is one of the most popular programming languages. As projects grow, their code can become complex which leads to code smells, signs that can indicate problems. Many tools are available to detect and fix these issues, but we need a comprehensive summary of their most important features. This paper provides a systematic literature review of JavaScript code smell detection tools. We searched four databases (Scopus, ACM Digital Library, IEEE Xplore, and Springer) using a specific search string to find relevant studies. To refine the results, we applied a four-step selection process, reducing 1002 initial studies to 18 by removing duplicates, filtering metadata, and reviewing their full texts. We then used backward and forward snowballing to find more relevant studies, increasing the total number to 27 primary studies. Finally, we examined these studies to analyze the code smell detection tools they described. We identified 22 tools, many published in top software engineering venues, such as ICSE, MSR and TSE. We found that most tools use rule-based linting (55%), which is efficient but struggles with complex architectural smells. Dynamic analysis (23%) is underused and AI-driven detection is completely missing, despite its relevance in modern software engineering research. Researchers are also developing framework-specific tools for modern JavaScript practices and focusing on the detection of test smells (22%). Most tools available to practitioners detect only basic smells and ignore deeper design issues. Tool builders can address these gaps by combining static and dynamic analysis and creating more adaptable tools. For researchers, the lack of AI-driven detection and modern benchmark datasets presents an opportunity for progress.

Software engineering principles aim to deliver high-quality products efficiently. However, as development progresses and new features are added, software quality can deteriorate without proactive measures. Refactoring helps maintain software quality by systematically restructuring code through small incremental changes without altering its behavior. A crucial step in the refactoring process is identifying code smells, which are design or structural flaws that increase software complexity, hinder maintenance, and contribute to duplication and rework. This study examines developers' knowledge of code smells and their perceptions of using SOLID principles to avoid them. To explore this relationship, we conducted a survey with 71 professional developers. Our results show no correlation between knowledge of code smells and the developer's academic background or experience level. Additionally, participants widely recognized the SOLID principles as an effective way of avoiding code smells. These findings reinforce the importance of studying code smells, understanding their refactoring techniques, and applying the SOLID principles for maintaining high-quality software products.

Test smells—poor design choices in test code—can hinder test maintainability, clarity, and reliability. Prior studies have proposed rulebased detection tools and manual refactoring strategies, most focus on statically typed languages such as Java. In this paper, we investigate the potential of Large Language Models (LLMs) to automatically refactor test smells in JavaScript, a dynamically typed and widely used language with limited prior research in this area. We conducted an empirical study using GitHub Copilot Chat and Amazon CodeWhisperer to refactor 148 test smell instances across 10 real-world JavaScript projects. Our evaluation assessed smell removal effectiveness, behavioral preservation, introduction of new smells, and structural code quality based on six software metrics. Results show that Copilot removed 58.78% of the smells successfully, outperforming Whisperer’s 47.30%, while both tools preserved test behavior in most cases. However, both also introduced new smells, highlighting current limitations. Our findings reveal the strengths and trade-offs of LLM-based refactoring and provide insights for building more reliable and smell-aware testing tools for JavaScript.

The extensive adoption of microservices architecture by technology companies is driven by its expected advantages, such as scalability, simplicity of development, and resilience, likely due to its cloud-native nature. However, the increasing complexity associated with this architecture can lead to the emergence of microservice smells, analogous to code smells, indicating potential architectural design issues. Despite the identification of numerous microservice smells in the literature, cohesive documentation to support architects detecting and refactoring them. This study conducts a Systematic Literature Review (SLR) to deepen the understanding of these microservice smells, explore detection tools and identify refactoring strategies to mitigate them. We conducted searches across six popular digital libraries, analyzing 27 relevant papers. As a result, we cataloged 104 distinct microservice bad smells, identified 7 detection tools, and compiled refactoring strategies for the most prevalent smells. This documentation aims to assist engineers and architects in identifying and effectively addressing microservice bad smells, thereby enhancing the quality and maintainability of microservice-based systems.

O objetivo deste artigo é saber como os Modelos de Linguagem de Grande Escala (Large Language Models -LLMs) impactam no ensino de programação. Atualmente muitos iniciantes nas linguagens de programação, em termos de criação, correção e explicação de código, vêm recorrendo às Large Language Models devido à sua facilidade em obter códigos prontos e explicações completas. Mas será que as LLMs causam impacto negativo ou positivo no ensino de linguagens de programação? Isso que esse artigo irá discutir.