With the increasing complexity of software systems, software developers would benefit from instant and continuous guidance about the system they are maintaining and evolving. Despite existing several solutions providing feedback and suggesting improvements, many tools require explicit invocation, leading to developers missing improvement opportunities, such as important refactorings, due to lost of train of thought. Therefore, to address these limitations, we propose an approach where developers receive instant and continuous feedback about their software systems. This guidance would include the detection of code smells and the suggestion of refactorings to improve the system, justified by relevant software quality metrics related to the recommendations. This research aims to improve the experience of developing and maintaining software systems by providing a live environment for continuous inspection and refactoring of software systems, that is informative, responsive, and tactically predictive, and thus helping developers to identify and solve quality problems in a quicker and better way.
Software systems are increasingly complex and extensive, and, as a result, approximately 75% of the costs associated with software development occur after finishing a particular system, or after inspecting it. Sometimes, simple tasks, like adding or modifying a feature, are generally hard and time-consuming due to the size and complexity of the system. Refactoring aims to mitigate existing code smells, usually a result of bad programming practices, without changing the current results while, at the same time, improving the maintainability and comprehensibil1i]t.y [
Several approaches are capable of detecting several code smells by analyzing specific software quality metrics. Also, there are already tools that suggest refactoring techniques to improve the overall quality of a program. However, the feedback provided to developers is not always detailed, fast enough, and optimal to efectively enhance the software systems. Then, we are exploring the introduction of liveness to enhance this guidance loop to provide real-time information that will help them change their programs beforehand so that when it comes to adding or modifying features, it will not be as hard for them as usuall2y].is [
The main objective of this research is to tighten the feedback loop associated with refactoring, making it immediate and continuous, during development, through the analysis of quality metrics, detection of code smells, identification of refactoring opportunities, and visualization of metrics related to each recommendation. Therefore, we aim to increase, improve, and speed up the feedback given to developers regarding their software systems. The main research question is to find the best combination of features to combine and provide in a live development environment, so that (1) developers can become aware of existing code smells, (2) refactoring opportunities can be appropriately suggested to developers, together with their expected quality impact, without being intrusive, (3) the developer experience can motivate them to quickly fix code issues, without strictly needing to compile or execute the system under development.
Liveveness is the possibility to shorten the edit-compile-run loop by providing real-time information to developers about their systems. Bringing liveness to the development of software systems makes them easier and simpler to understand, visualize, maintain, and evol2v].e [
In 1990 and later in 2013, Tanimoto proposed a hierarchy composed of several liveness levels. The first level is merely an informative level, where developers had access to information using diferent visual methods such as flowcharts. Level two was a more evolved level where developers needed to ask for a response from their systems, and shortly afterward, they could check the results obtained. In level three, computers would wait for programmers to stop developing their systems showing the results of the respective program automatically. In the fourth level, the computer did not wait for the developer to finish programming since it was executing the program while it was being created, instantaneously showing its results. In level ifve, the computer not only runs the software while it is being developed but also forecasts a group of actions that the programmer may be interested in, executing one or more versions of these predicted actions. Finally, in level six, the forecasted steps are strategically selected to cover the majority of the software behaviors3[].
Currently, there are some live tools like Quokka, which is a live visualization tool of Kaluta emulations (enterprise software emulator able to represent large-scale environments), enabling a developer to see the emulation’s endpoints and the respective interactions with external software systems while they are occurring4[].
We also have the concept oCfode Smells. A code smell is any bad implementation characteristic
present in the source code of any software system that can eventually represent a more profound
problem [
Tarwani et al.6[] used aGreedy algorithm to determine the optimal refactoring sequence to be executed in a program. Each refactoring produces a specific maintainability degree, and the Greedy algorithm tries to find the chain of refactorings that will lead to the higher maintainability value. It supports refactorings l“iEkxetract Method”, “Move Method”, “Extract Class”, etc. Meananeatra7[] used a methodology to obtain the best refactorings to so“lLvoeng Method” smells. He used a four criteria method, to select the optimal sequence, composed by (i) the number of code smells removed(i,i) the maintainability degree of the solutio(nii,i) the size of the created sequence, an(div) the number of elements of the source code changed. This approach includes refactorings such“Dasecomposed Conditional”, or“Replace Method with Method Object”.
Although there are already advances in detecting code smells, identifying refactoring opportunities, and developing live tools, they are not well integrated yet. They do not capitalize on all the existing potential, such as giving immediate feedback and guidance to programmers. By combining these approaches, first, and to explore their synergies, after, we are convinced that it will be possible to tighten and improve the support provided to developers. They would have instant and continuous access to their code quality through the detection of specific smells and identification of refactoring opportunities, while coding, and they could choose the most appropriate actions based on the impacted metrics (i.e., before versus after refactoring).
This section describes all of our main research objectives, stating the hypothesis and research questions that we aim to answer with this project. Besides, we summarize the approach that we intend to use to develop and validate our solution.
This project aims to tighten the refactoring feedback loop, making it instantaneous and continuous, while developers are programming. We expect to achieve this objective by analyzing software quality metrics and suggesting and applying refactoring methods to solve several code smells. Besides, we want to provide information about the evolution of specific metrics related to the refactoring recommended to complement the feedback given to the programmers.
Therefore, this research project is based on the hypothesis t“hAathigher level of liveness combined with the constant exposure to refactoring suggestions can increase the overall quality of software systems and reduce their development time.”
Based on the previous statement, the main research questions of our project are: RQ1 ““Are the identified refactorings capable of mitigating the code smells detected?” We aim to verify if the refactorings suggested by our approach are able to extinguish the code smells detected on the source code.
RQ2 “When developers constantly receive refactoring suggestions, can they reach better programming solutions, with more quality?” We aim to analyze if developers can converge to better programming solutions when they are constantly exposed to refactoring suggestions complemented by information about specific metrics that will be increased when a refactoring is applied.
RQ3 “When we apply a higher level of liveness in a refactoring suggestion approach, are developers able to shorten their total development time?” We aim to verify if it is possible to reduce the development time when developers know which refactorings they should apply on their code.
Our research project will mainly followEtnhgeineering Research Method [
The development of our solution will be divided into four implementation stages. In the first
stage, we want to analyze a set of quality metrics that will be used to detect specific code smells
on a project. To calculate each metric, we will analyze the program’s abstract syntax tree and,
when necessary, it will apply mathematical formulas to measure specific metrics like the volume
of a method [
We also expect to execute diferent validation tests, using thoebservational andcontrolled methodologies to validate the proposed approach. We expect to execute diferent experiments, using academic and industrial case studies, to achieve the main goals on the validation of our solution. Each participant will have to complete a list with several programming tasks, with and without the developed tool. We will then use hypothesis tests with the data collected to validate our research questions and the main hypothesis. Besides, we aim to create robotic developers, who guided by public git repositories, will use the proposed tool in both a full and semi-automated way to change code driven by commits and assess the expected quality with and without doing the recommended refactorings.
During the development of the master’s thesis, we implemented a plugin for Visual Studio Code,
for JavaScript and TypeScript programs, which analyzed several software quality metrics, while
developers were programming their systems. In this project, we calculated metrics like the
number of lines of code, cyclomatic complexity, or maintainability degree. The measurement of
each metric was done using the abstract syntax tree (AST) or specific mathematical formulas
[
After developing that tool, we tried to validate our hypothesis by doing an empirical study with programming students. However, we used a very simple case study, with a low complexity degree, which did not allow us to collect enough relevant data to validate any of the research questions of that project or even its main hypothesis.
Regarding the current doctoral research project, we already analyzed the problem that this Ph.D. will solve. We proposed the respective, and we also studied the current state-of-the-art on the main topic of this project. Besides, we already started our tool by analyzing some software quality metrics that were not included in the master thesis’ project.
As mentioned before, we already started developing the proposed tool, and currently, we are analyzing more quality metrics, and we are also cataloging the metrics and associated code smells.
As future work, after finishing the catalog, we expect to start the mechanism to detect code smells using the measured metrics and the developed catalog. We also intend to use machine learning and data mining algorithms to predict parts of the code that can sufer from some bad programming practices. Then, after detecting the code smells, we want to create a catalog that associates each code smell and respective metrics with the refactoring techniques that can solve them. We will use Fowler’s refactorings cata1l]ogfo[r that. However, we also want to investigate more code smells and refactorings beyond the ones already known. After ifnishing this catalog, we intend to apply intelligent algorithms to suggest the optimal sequence of refactorings for a given programming context. In each refactoring indicated, we also expect to present the evolution of specific software quality metrics to complement the information provided to developers. After this last development step, we will implement the mechanism that will automatically execute a refactoring when a developer accepts the refactoring suggestion provided by our tool.
Next, we plan to confirm the main hypothesis using hypothesis tests with the data collected through the controlled experiment. In this experiment, we pretend to use academic and industrial case studies. Finally, in the last step, we intend to write the respective dissertation.
With this, we expect to achieve three diferent results. The first one is the state-of-the-art analysis, which aims to introduce the current approaches, techniques, or tools related to the most relevant topics of this thesis. Secondly, we aim to develop a live refactoring suggestion tool for Visual Studio Code that will allow developers to receive feedback – in the form of restructuring recommendations – about their software systems, while they are programming.
More and more, developers need to have support tools that help them understand and change their software systems. When developers have to maintain their programs, sometimes they have great dificulty in doing precisely that, because their code is hard to read. Then, they have to refactor the code turning it more clean and self-explanatory, increasing its overall quality.
Therefore, we proposed a new tool capable of doing exactly that. This tool has its merit and respective impact, mainly regarding the software development cycle, since it focuses on the development and maintenance stages, inspecting the code to find possible problems. We think that this project has several benefits: (1) eficiency, as it is expected that through this approach the software development time could be reduced significantly; (2) automation, because the suggestions will be made automatically while the developer is programming; and (3) source code quality since it is expected that at the end, the source code would have better quality. We also believe that our approach has an impact in the area of Software Engineering, because (1) our approach helps developers to understand and correct their systems, if necessary, in early development stages; and (2) can be used in the industry, simplifying their systems that usually are complex, with millions of lines of code.
In this appendix, we present the Gantt Chart of our work plan with the idealized tasks and main objectives of our Ph.D. research project. We also describe the diferent tasks, milestones, and papers that we aim to publish about the results we achieve over this project.
In this appendix, we present the poster that summarizes our Ph.D. research project. There, we give an overview of our motivation, main objectives, and proposed approach. M o t i v at i o n
Besides developing software system s, developers need to m ain t ain them ; The ef f or t and t im e needed to u n der st an d
or m ain t ain a com plex software system are very h igh ; Developm ent environm ents already give
som e assist an ce to developers; But they could provide bet t er r eal-t im e f eedback and su ppor t .
Ob j ect i v es
In cr ease, im pr ove, and speed u p the feedback about the qu alit y of t h e code design , given to developers regarding their software system s:
Helping developers to m ake bet t er decisions about the code design; In cr easin g the source code quality; Speedin g-u p the convergence to a good solution.
Li ven ess
Real-time feedback that
shortens the edit-compile-run
cycle [
Sof t w ar e M et r i cs
Measurement of specific
software characteristics [
Cod e Sm el l
Surface indicator that usually
corresponds to a deeper
problem in the system [
Ref act or i n g
Changes made in a software
system, without modifying the
behavior implemented [
Sar a Fer n an des* , Adem ar Agu iar * ^, An dr é Rest ivo* + * Facu lt y of En gin eer in g, Un iver sit y of Por t o ^IN ESC-TEC, +LIACC
RQ1: Are the identified refactorings capable of mitigating the code smells detected? RQ2: When developers constantly receive refactoring suggestions, can they reach better programming solutions, with more quality? RQ3: When we apply a higher level of liveness in a refactoring suggestion approach, are developers able to shorten their total development time?
VSCode Ext en sion that analyzes sof t w ar e m et r ics, in real and program m ing tim e, to detect specific code sm ells; Then, it suggests r ef act or in g techniques to solve the code sm ells, pr ovidin g inform ation about the evolution of particular m et r ics.
Developm ent of a tool for VSCode that analyzes qu alit y m et r ics in real and program m ing tim e; It also detects "Extract Variable" and "Split Variable"
We propose a solution capable of providing live
Developm ent of the proposed tool for VSCode; Em pirical validation of the h ypot h esis, using