Extending Actionability in Better Code Hub Suggesting Move Module Refactorings
Total Page：16
File Type：pdf, Size：1020Kb
Extending Actionability in Better Code Hub Suggesting move module refactorings Teodor Kurtev [email protected] July 14, 2017, 48 pages Supervisor: dr. Ana-Maria Oprescu, [email protected] Host supervisor: dr. Magiel Bruntink, [email protected] Host organisation: Software Improvement Group, Inc., https://www.sig.eu Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering http://www.software-engineering-amsterdam.nl Abstract Undoubtedly, refactoring can have a positive effect on overall system quality, and it is a critical part of the work cycle of every developer. However, finding the right refactoring opportunities can be a difficult task. This is particularly the case for refactorings related to overall system structure. One of the best ways to address such issues is to apply the move module refactoring. In this thesis, we propose a way of automatically detecting refactoring opportunities for move module refactorings in the context of the C# language using a Compiler as a Service (CaaS) - Roslyn. We evaluate our approach using seven open source projects and an expert panel. The results from these validation experiments showed our approach as promising - the group of experts found more than half of the proposed refactorings useful. 1 Contents Abstract 1 Acronyms 5 1 Introduction 6 1.1 Problem analysis....................................... 6 1.2 Research questions...................................... 7 1.3 Solution outline........................................ 8 1.4 Definitions........................................... 8 1.5 Outline ............................................ 8 2 Background 10 2.1 Refactoring .......................................... 10 2.2 Code smells.......................................... 10 2.3 Move module refactoring................................... 11 2.4 Better Code Hub (BCH) and the SIG Maintainability Model .............. 11 2.5 Construction of the Undirected weighted class dependency network (uWCDN) and Undirected feature dependency network (uFDN) ..................... 12 2.6 The Java and C# languages................................. 12 2.7 The Roslyn compiler..................................... 13 2.8 Pareto efficiency ....................................... 13 3 Motivating Examples 15 3.1 Improving refactorings.................................... 15 3.2 No change refactorings.................................... 15 3.3 Non-beneficial refactorings.................................. 16 3.4 Balance vs Independence - reflection............................ 16 4 Prototype design research method 18 4.1 Assumptions ......................................... 18 4.2 Problem analysis....................................... 19 4.2.1 SIG context...................................... 19 4.2.2 General context.................................... 19 4.3 Solution design........................................ 20 4.4 Validation........................................... 20 5 A proof-of-concept refactoring tool 22 5.1 Research context....................................... 22 5.2 Refactoring approach..................................... 22 5.2.1 High-level tool design ................................ 23 5.2.2 Java syntax vs C# syntax.............................. 23 5.2.3 Gathering code data................................. 24 5.2.4 Construction of the uFDN and uWCDN...................... 24 5.2.5 Detecting improvements in external dependencies of modules.......... 25 5.2.6 Algorithm for detecting possible move module refactorings............ 26 2 CONTENTS 5.2.7 Filtering recommendations ............................. 27 5.2.8 Ranking recommendations.............................. 27 5.3 Components mapping and their role in the context of Better Code Hub . 28 6 Evaluation 29 6.1 Validation setup ....................................... 29 6.1.1 Targeted systems................................... 29 6.1.2 Gathering dependency empirical data ....................... 30 6.1.3 Evaluation using the SIG Maintainability Model ................. 31 6.1.4 Evaluation using an expert panel.......................... 31 6.1.5 Ordering refactoring using Pareto efficiency.................... 31 6.2 Results............................................. 31 6.2.1 Initial refactoring data................................ 31 6.2.2 Empirical data regarding dependencies....................... 32 6.2.3 SIG maintainability model evaluation ....................... 32 6.2.4 Evaluation using an expert panel.......................... 34 6.2.5 Ordering refactoring using Pareto efficiency.................... 35 7 Discussion 37 7.1 Discussion per test system.................................. 37 7.2 General discussion and reflection on usefulnesses ..................... 38 7.2.1 Improvements..................................... 39 7.2.2 Limitations...................................... 39 7.3 Using a CaaS(Roslyn) - lessons learned........................... 40 7.4 Answering the research questions.............................. 41 7.4.1 RQ 1 - Can we adapt existing approaches for move module refactorings to C# projects? ....................................... 41 7.4.2 RQ 2 - How can we design a prototype tool that implements existing refactoring approaches for move module refactorings?..................... 41 7.4.3 RQ 3 - How can a CaaS be used as a basis for a code analysis tool? . 42 7.5 Threats to validity...................................... 42 7.5.1 Conclusion validity.................................. 42 7.5.2 Construct validity .................................. 42 7.5.3 External validity................................... 42 8 Related work 43 8.1 Programming language and MRRA............................. 43 8.2 Postconditions and preconditions.............................. 43 8.3 Community definition .................................... 43 8.4 Refactoring selection criteria ................................ 43 8.5 Refactoring ordering..................................... 43 8.6 Validation........................................... 44 8.7 Summary ........................................... 44 9 Conclusion and future work 45 9.1 Future work.......................................... 45 Bibliography 47 3 Acknowledgments I would like to express my sincere gratitude to both my supervisors - Ana-Maria Oprescu and Magiel Bruntink, as their constant feedback and advice was a critical factor in the success of this project. Furthermore, I would like to thank everybody else at Software Improvement Group (SIG) for providing me with the opportunity to write my thesis there and the help they offered me in every way possible. Finally, I would like to thank all my friends who helped me in the hardest of moments. Teodor Kurtev Amsterdam, The Netherlands July 2017 4 Acronyms BCH Better Code Hub.2,6{8, 11, 12, 18{20, 22, 25, 28, 41 CaaS Compiler as a Service.1,3,7, 13, 40, 42 TAR Technical Action Research. 18 uFDN Undirected feature dependency network.2,8, 12, 24{26 uWCDN Undirected weighted class dependency network.2,8, 12, 15{17, 22{26 5 Chapter 1 Introduction Refactoring is an essential part of every software project life cycle and as stated by Robert Glass - "Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs." [1]. Therefore, it is safe to assume that any help in automating refactoring would be a great asset for software development teams. However, before we can delve into refactoring, we first need to know that there is a problem in our code. Code analysis techniques have certainly progressed far in recent years, and we could quickly build a tool that analyzes code and produces a list of problematic areas. However, a more interesting problem is how to propose fixes for these problems. In this thesis, we introduce a general approach for detecting possible move module refactorings in the context of the C# language and evaluate its practical usefulness. We define a module as a group of declaration - class, struct, enum or an interface. Additional ideas on how to group modules(assign them to components) and how to present and order our produced refactorings are discussed. To illustrate the problem in a practical environment, we chose a web tool developed by our host company - Better Code Hub (BCH)1. The core idea of the application is to grade a project maintain- ability on metrics described in the SIG Maintainability model [2] and providing a list of problematic areas in the code. However, BCH we want to extend the actionability of the tool by providing refac- torings for these problematic areas. To do that, we apply our proposed refactoring recommendation algorithm in the context of BCH and assess its effectiveness. We hope that by providing a list of actionable items, we will increase the value of BCH system for its users. Component Independence is defined as having loose coupling between top-level components. Our aim is to improve the Component Independence in BCH by proposing move module refactorings. Our rationale for choosing this metric is that code smells related to system structure are, by their nature, harder to detect and refactor. We hope that our approach will help developers by offering them a list of possible refactorings they can apply. 1.1 Problem analysis In a general context - automatic proposal of refactorings is not a new area. Significant research [3] has been done already, and at first glance, this particular problem should have excellent solutions and tooling. However, this is not the case, as we found almost no tools for the Java and .NET ecosystems(or