ANALYZING REFACTORING TRENDS AND PRACTICES IN THE SOFTWARE INDUSTRY

---Most of the developers in the software industry though have some instinctive capacity to refactor but the true expertise of this skill is rarely found in real time software development. Thus it is significant to discern the reasons as to how prevalent are the refactoring practices in reality are and what are the major factors impacting its role and adoption in software development. This paper explores the actual implementation of refactoring practices in software industry by taking inputs from the software professionals working in different projects and companies. This exploration is basically required to assess the gap between research practices and Industrial norms. The paper also tries to probe the consequences in software development in the absence of refactoring, what are the code rejuvenation practices adopted by the professionals when not refactoring or due to non familiarity or lack of expertise in the area.


I. INTRODUCTION
Comprehension exercises on the various existing software engineering (SE) practices and techniques used in industry are significant as it gives a real insight into the applicability of the theoretical theories and practices evolving rapidly. There exists a wide range of software practices and their types that are imbibed by the industry.
The drive for conducting the research on this topic is derived from various sources. First, refactoring has gained momentum in the industrial practices, along with widespread research and the rapid increase of tool support for automated refactoring [12] [13] . A significant question in this context would be: Can the benefits of refactoring be quantified and, if so, is it worth doing refactoring? What is the status of refactoring in the software industry? By exploring various works on refactoring, there has only been a confined research to highlight the role of refactoring in evolving commercial software and little research to establish the relevance of the refactored code with ease of maintenance or fault-proneness.
The other aspect that the paper tries to explore is the consequences resulting in the absence of refactoring. What are the code rejuvenation practices adopted by the professionals in absence of refactoring or due to non familiarity or lack of expertise in the area. How does it impact the software development process and creation of technical debt? These explorations would to an extent assist in bridging the gap between research practices and Industrial practices. Thus it intends to grasp and identify high level view on Software Engineering and maintenance Practices primarily used in the industry. A lot of research has already been conducted on refactoring techniques and tools. Most of the researchers have claimed that it helps in easing up the maintenance process. In another research it was found that not just the software metrics but the type of design the developer perceives is what influences the process of refactoring and at times the crosscutting concerns becomes a concern and need to be refactored [21] [23]. One of the works suggested that the code smells and its severity may vary from one developer to the other and the significance of the class with the code smell also varies according to different developers as the code evolves [17] [20]. Thus a trade-off between the quality and robustness is worth calculating before refactoring. Automated refactoring too have been explored extensively by the researchers and various approaches are already invented using search based techniques to assist in searching for a better design [24].Another important impact that has been explored by a few researchers lately is the improvement in the energy efficiency of the software due to refactoring [2][25] [26]. The carbon footprint contributed by the ICT is around 2% of the total emission [25] [27] . Refactoring has led to reduction in code smells and a better software design contributing to improved energy efficiency in ICT. Though this aspect has not been investigated in this paper but it would be explored in the future work.
This drove us to concentrate on two main objectives that are:  Enquire and analyze the major refactoring trends in the industry  What maintenance strategy is used to improve the software  If not refactored then how the code does survive recursive modifications.

II. METHODOLOGY
The Delhi NCR region in India has a vibrant software industry and is worth exploring the Software engineering practices and in particular the status of refactoring. Our objective is to get a glance of the high-level view on type of SE practices in an Industrial setup. To investigate the status of refactorings in the SE practices, we drafted an online and face to face survey with 10 questions based on the experience of the developer and his role.
The questionnaire that had been designed had the following queries:

III. ANALYSIS AND RESULTS
This paper elaborates the significance and the status of refactoring in the software industry by performing the survey of refactoring practices and attitudes in different companies working on different domains in different teams. The study explores differences in expertise and attitudes about refactoring among participants who played roles in software development, and how these differences affected the actual practice. Many authors who had conducted research on the impact of refactorings claim substantial improvement in maintainability [1][9] [10]. The study found that though refactoring at different stages and the roles is endorsed by the participants but full bloom refactoring with an in-depth knowledge about the code smells is very rare and refactoring needs to be practiced more often as there is a strong agreement about the negative impacts of deferring refactoring on the overall project.
We had carried out a large-scale empirical study that explored the views and experiences of approximately 80 experienced practitioners with regards to the prevalence of refactoring activities in mainstream development. We had conducted face to face interactions as well as email-based semi-structured interviews and had analysed different parameters impacting the adoption of this practice.

A.
Absence of a Standard Strategy The survey revealed that there are no strategies in place for implementation of refactoring techniques. No plans designed to guide the developers with the same. Developers performing with their own knowledge and sometimes ended up messing with the code. This indicates that the introduction to the code smells [15] should be made mandatory to the development teams. Though the agile team, practicing the test driven development had different perspectives and a deeper understanding of the phenomena [3][4]. Analysis of the survey results have raised many interesting questions suggesting the need for a considerable amount of future research.

B.
Analysis of the Feedback The developers are indulged in refactoring but somewhat in an informal state though the ones whom we surveyed had knowledge about the topic but not good enough to implement it practically. The survey was conducted on 5 teams (named as A, B, C, D, and E) belonging to different organizations (refer to table 1) each following its own software development strategy.
As has been surveyed earlier by other researchers refactoring is not just a phenomenon to smoothen the code but it comes with its own cost and risks [5]. The first team, from Organization A had given a poor response due to the lack of knowledge in the area of refactoring. No one in the team actually was practicing refactoring as they quoted the project being relatively smaller and given the time constraints they could not embark on something less known. Generally a failing code is quick fixed by the developer with his own reasoning and instinct. All the developers were involved in all the tasks and hardly had any specialized person for carrying out task like testing.
The Company D that deals in formulating and delivering website design and development projects uses agile methodology combined with SDLC (system development lifecycle) that helps them ease the whole process. As per the feedback of the developers they had experienced that deferred refactoring sometimes would incur more cost and risk, so the best approach is to follow the test driven development. The team had designated testers for that task.
The company E that works in the domain of Health Care Finance and Enterprise claims to have a good experience in agile development with expert testers for automation testing, manual testers and even unit test writers who assist with the Test Driven Development [8].Agile teams seem to have a better planning in this regard [1]. Generally follow test last approach but a few also follow Test first approach High level code smells identified by tools. Code rigidity is a bad symptom where there is a lot of dependencies amongst the methods and on other related objects.
Configuration data not in a centralized location and scattered through the code reflects bad coding.

IV. MAJOR REASONS ABOUT USING OR NOT USING REFACTORING
The reasons professionals quoted for not refactoring a design can be broadly categorized as follows: A. Deadlines: The business pressure to complete the task in a given frame of time on a specific deadline is usually immense on the team as the stakeholders usually decide on the deadlines with the manager without consulting the developers. This also is a big reason for the introduction of technical debts and ironically calls for refactoring in return [16]. It has also been observed that the development teams are not very keen on pursuing the proactive refactoring [4] [6] unless there is some business driven requirement or if there is an acute need to refactor because of the deteriorating performance of the product.

B. Lack of Tests
Refactoring without proper testing becomes worthless. Hence if a developer refactors without testing the code there's no way to ensure if the developer has introduced a bug or has changed the behavior. To maintain the code, some good testers should always be available but that's not the case always in most of the projects refactoring without a proper test plan usually takes the developer a week behind on the roadmap without assurance of any improvement.

C. Troublesome and risky.
It has been cited frequently by many authors that to refactor is not an easy task and involves risk in particular introducing new faults or other problems [7][8] and many a times behavior preservation becomes quite difficult especially when inheritance is involved.

D. Technical
Participants reported there are various technical that limit refactoring such as inadequate tool support reasons include the nature of the project t refactoring. Examples include like working on legacy system that lack test suites, having to implement a third party interface, non familiarity with the code etc professionals working on a legacy system have to put in extra effort to refactor it, especially legacy systems developed in C needs major code rejuvenation practices due to the lack of object oriented constructs, techniques have been invented to refactor the code to produce a maintainable and readable code [18] [19]. detailed discussion about the various barriers to refactoring has been highlighted by various researchers already [11] [14]. The management support is also a factor as the participants reported that they have to comply with the plan of their boss.
. Fig 1: Refactoring pattern in the surveyed organization E. Analysis of the participants' background: As indicated in Fig 1, it depicts how the respondents Company A, B, C, D and E perceive and implement refactoring. As can be seen from the figure the Company A has hardly any candidates those have adopted refactoring strategy and there are many who have no idea about it. An important observation in this case would be to assess the background of the developers as well. There were almost 5 to 15 % candidates those were fresher or having less than years of experience. These respondents could hardly speak about refactoring. Almost 60 % of the candidates were from the core computing background with bachelors or masters degree and they depicted greater curiosity and awareness.
International Journal of Advanced Research in Computer Science, 9 (5), Sept-Oct 2018, the quality in ould always be available but that's not the case always in most of the projects. Therefore refactoring without a proper test plan usually takes the without assurance frequently by many authors that to refactor in particular introducing [7][8] and many a times behavior preservation becomes quite difficult especially there are various technical constraints tool support. Other project that inhibits . Examples include like working on legacy having to implement a thirde, non familiarity with the code etc. The professionals working on a legacy system have to put in extra effort to refactor it, especially legacy systems rejuvenation practices due so various techniques have been invented to refactor the code to produce a maintainable and readable code [18] [19]. A ussion about the various barriers to refactoring been highlighted by various researchers already The management support is also a factor as the participants reported that they have to comply with the plan Fig 1: Refactoring pattern in the surveyed organization it depicts how the respondents from D and E perceive and implement refactoring. As can be seen from the figure the Company A has hardly any candidates those have adopted any planned refactoring strategy and there are many who have no idea An important observation in this case would be to assess the background of the developers as well. There were almost 5 to 15 % candidates those were fresher or having less than 2 years of experience. These respondents could hardly speak about refactoring. Almost 60 % of the candidates were from the core computing background with bachelors or masters and they depicted greater curiosity and awareness.
Whereas approximately 30 % of the candidates were from a non computing background such as electronics, electrical or mechanical aswell who found the concept to be difficult to acquire and would not choose to refactor unless it is explicitly required. But for sure the programmers were keen to somehow do away with the technical debt.

V. CONCLUSIONS AND FUTURE WORK
The interactions from five industrial companies explore some conceptions about the refactoring practices in the industry. The goal of this study was to provide insights into the practice of refactoring in processes. This questionnaire-based survey performed directly as well as indirectly via email provides results from approximately 80 respondents. industry still lacks experts in the area and developers in general are reluctant to learn or adopt the skills due to a number of constraints such as time, skills and risk etc. per the survey results refactoring doesn't seem to overall maintainability or the complexity metrics unless performed with a proper layout and plan. Refactoring changes made on a random basis hardly has any impact infact they carry the risk of introducing bugs in the program. The principal results concerning planning and implementation of refactoring indicates 80 % of agile team members do careful planning during good idea about refactoring and related tasks like TDD whereas rest of the teams had a relatively lower percentage (approx 20 to 30%) of the participants responding towards careful planning for refactorin exhaustive case as the numbers of participants are small but the projections do indicate the highlight the gap between research practices usage. The future work would be participant with broader parameters for assessment. 0 % of the candidates were from a non computing background such as electronics, electrical or mechanical aswell who found the concept to be difficult to acquire and would not choose to refactor unless it is required. But for sure the experienced programmers were keen to somehow do away with the CONCLUSIONS AND FUTURE WORK industrial companies explore some conceptions about the refactoring practices in the was to provide insights into refactoring in software development based survey performed via email provides results from . The study found that still lacks experts in the area and developers in general are reluctant to learn or adopt the skills due to a number of constraints such as time, skills and risk etc. As per the survey results refactoring doesn't seem to impact the or the complexity metrics unless it's performed with a proper layout and plan. Refactoring changes made on a random basis hardly has any impact infact they carry the risk of introducing bugs in the program.
oncerning planning and plementation of refactoring indicates 80 % of agile team do careful planning during the project and have a good idea about refactoring and related tasks like TDD whereas rest of the teams had a relatively lower percentage participants responding similarly careful planning for refactoring. The study is not an exhaustive case as the numbers of participants are small but do indicate the refactoring trend and highlight the gap between research practices and industrial usage. The future work would be directed to a wider with broader parameters for assessment.