Barriers to Refactoring: Issues and Solutions

Refactoring mechanism is commonly used in software development. Though Object oriented programming promotes ease in designing reusable software but the long coded methods makes it unreadable and enhances the complexity of the methods. The common code defects are associated with large classes and methods. To ease up the code comprehension Extract method, Extract class serves as a comfortable option to reduce the disorganization and duplication of the code to produce more fine grained methods and classes. Though refactoring serves as an important mechanism to improve the software quality whether performed manually or in an automated way with the help of tools or IDEs but there are umpteen cases where refactoring could lead to deterrent effect. This paper intends to explore the various problems and barriers associated with refactoring and specifically while extracting the code (extract method, extract class, extract interface) and their solutions

On Using UML Diagrams to Identify and Assess Software Design Smells

Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells

Behind the Scenes: On the Relationship Between Developer Experience and Refactoring

Refactoring is widely recognized as one of the efficient techniques to manage technical debt and maintain a healthy software project through enforcing best design practices, or coping with design defects. Previous refactoring surveys have shown that code refactoring activities are mainly executed by developers who have sufficient knowledge of the system’s design, and disposing of leadership roles in their development teams. However, these surveys were mainly limited to specific projects and companies. In this paper, we explore the generalizability of the previous results by analyzing 800 open-source projects. We mine their refactoring activities, and we identify their corresponding contributors. Then, we associate an experience score to each contributor in order to test various hypotheses related to whether developers with higher scores tend to 1) perform a higher number of refactoring operations 2) exhibit different motivations behind their refactoring, and 3) better document their refactoring activity. We found that (1) although refactoring is not restricted to a subset of developers, those with higher contribution score tend to perform more refactorings than others; (2) while there is no correlation between experience and motivation behind refactoring, top contributed developers are found to perform a wider variety of refactoring operations, regardless of their complexity; and (3) top contributed developer tend to document less their refactoring activity. Our qualitative analysis of three randomly sampled projects show that the developers who are responsible for the majority of refactoring activities are typically in advanced positions in their development teams, demonstrating their extensive knowledge of the design of the systems they contribute to

EOLANG and φ\varphi-calculus

Object-oriented programming (OOP) is one of the most popular paradigms used for building software systems. However, despite its industrial and academic popularity, OOP is still missing a formal apparatus similar to $\lambda$-calculus, which functional programming is based on. There were a number of attempts to formalize OOP, but none of them managed to cover all the features available in modern OO programming languages, such as C++ or Java. We have made yet another attempt and created $\varphi$-calculus. We also created EOLANG (also called EO), an experimental programming language based on $\varphi$-calculus

Koneoppimisen käyttäminen ohjelmistojen refaktoroinnissa

Tiivistelmä. Refaktoroinnilla tarkoitetaan ohjelmakoodin muokkaamista ja siistimistä helpommin ymmärrettävään muotoon, muuttamatta koodin ulkoista toimintaa. Refaktoroinnin seurauksena ohjelmointityö etenee sujuvammin ja samalla vältetään projektin ajautumista ongelmiin. Refaktorointi ei kuitenkaan ole helppo toimenpide, ja epäonnistuessaan se voi aiheuttaa huomattavia kustannuksia. Tämän vuoksi suositellaan laajojen operaatioiden sijasta kevyttä refaktorointia päivittäisen ohjelmointityön ohessa. Refaktoroinnin haasteita ovat käytössä olevan ajan vähyys, monimutkaiset ongelmat, puutteellinen työkalujen tuki ja riskit toimivan koodin rikkomisesta. Koneoppimisella tarkoitetaan tietokonejärjestelmiä, joiden toiminta kehittyy automaattisesti kokemuksen kautta. Koneoppimista voidaan soveltaa monimutkaisten ongelmien ratkaisemisessa, joihin kuuluu esimerkiksi automaattinen kasvojen tunnistaminen. Tämän tutkielman tarkoituksena on selvittää koneoppimisen käyttömahdollisuuksia automaattisessa refaktoroinnissa. Tutkielma osoitti, että koneoppimisen avulla voidaan tunnistaa lähdekoodista kohtia refaktorointia varten, mutta menetelmät eivät ole vielä valmiita ja aiheen tutkimus on yhä kesken. Työkaluilta vaaditaan paljon, sillä tehtävä on vaikea ja vääriä tuloksia ei voida hyväksyä. Manuaalisessa refaktoroinnissa tärkeää on versionhallinnan ja kattavien yksikkötestien käyttö turvallisuuden takaamiseksi. Automaattinen refaktorointi vähentäisi kuitenkin kehittäjien työtä huomattavasti

Model-based source code refactoring with interaction and visual cues

Refactoring source code involves the developer in a myriad of program detail that can obscure the design changes that they actually wish to bring about. On the other hand, refactoring a UML model of the code makes it easier to focus on the program design, but the burdensome task of applying the refactorings to the source code is left to the developer. In an attempt to obtain the advantages of both approaches, we propose a refactoring approach where the interaction with the developer takes place at the model level, but the actual refactoring occurs on the source code itself. We call this approach model-based source code refactoring and implement it in this paper using two tools: (1) Design-Imp enables the developer to use interactive search-based design exploration to create a UML-based desired design from an initial design extracted from the source code. It also provides visual cues to improve developer comprehension during the design-level refactoring process and to help the developer to discern between promising and poor refactoring solutions. (2) Code-Imp then refactors the original source so that it has the same functional behavior as the original program, and a design close to the one produced in the design exploration phase, that is, a design that has been confirmed as “desirable” by the developer. We evaluated our approach involving interaction and visual cues with industrial developers refactoring three Java projects, comparing it with an approach using interaction without visual cues and a fully automated approach. The results show that our approach yields refactoring sequences that are more acceptable both to the individual developer and to a set of independent expert refactoring evaluators. Furthermore, our approach removed more code smells and was evaluated very positively by the experiment participants.</p

Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring