Refactoring Industrial-Strength Code

Transcription

1 Refactoring Industrial-Strength Code Refining code toward better design Usman Parvez Department of Computer Science National University of Computer and Emerging Sciences Lahore Pakistan Abstract Good software design leads to a reusable system that is easier to extend and evolve. Better object-oriented design always leads to more modular, flexible and robust system. Factors like time and resource constraints in industry result in compromise of good object-oriented design. Adding features or extending legacy systems is always very difficult. Software Refactoring allows to change the internal structure of a software system without changing its observable behavior. Refactoring doesn t guarantee that the performance of the system would improve but make its maintainable and extensible. In this thesis, we understand an industrial code, identified different code smells and provided appropriated refactoring technique for more readable and modular system. Further we have suggested code smells and there appropriate refactoring technique that have not been listed by Martin Fowler. Keywords-component; Refactoring; Code Smells; Anti Pattern; I. INTRODUCTION In our research we have targeted industrial strength code. The application is in production in several organizations worldwide. The application has evolved drastically and has consumed over 10 man-years. It has been developed using PowerBuilder an IBM Tool for Rapid Application Development. As the application has evolved the design of the application has been compromised resulting into difficult to maintain and inextensible system. The reasons for this were diverse: Multiple Clients input Domain Complexity Incomplete and unstable requirements Frequent changes under pressure of time Underestimation of the complexity Lack of documentation rules Drop out of project leaders Inexperienced developers In our study we focused on understanding the Domain and model it using both the Top down and Bottom up approaches [17]. Further we analyzed and identified code smells that exists in industrial strength code and suggested refactoring techniques for their mitigation. Importance of design can be analyzed in large Enterprise level systems having numerous clients connected. Maintainability and extensibility are the major factors associated with it. Code smells are the symptom in the source code of a program that possibly indicates need of code refactoring. Common code smells found in code are Duplicate Code, Large Method, Large Class, Feature Envy, Inappropriate intimacy, Refused bequest, Lazy class, Duplicated method and Contrived Complexity [8]. Refactoring of code is ensured to remove the code smells. Importance of Refactoring code has been done informally for years. However, The first thesis on program restructuring (Refactoring) was done by Opdyke, William [4][5]. Refactoring is gaining its acceptance among software developers [2] and has been defined as the process of changing a software system in such a ways that results into improved internal quality and preserving its external behavior. The process could be informally referred to as "cleaning up" or "taking out the garbage" [6]. Refactoring neither fixes bugs nor adds new functionality, though it might pave the way either activity but it do improves the understandability of the code, changes its internal structure and design, and removes dead code. In short it refines the original source. Goal. We want to examine the code smells and deterioration of software design due to rapid change in system. We believe that the design of the system is initially developed at the start of the project within 3-6 months of the project life cycle and rest it s the coding that takes part in development. During the development and maintenance phase there is high chance of code deterioration due to change in business domain, frequent changes under pressure of time, inexperience resources and lack of documentation rules, until software design is refactored accordingly. Our study was to identify the code smells in code that are commonly found in industrial code about are not listed and are different than smells listed by Fowler [3-5]. Contribution. We present a case study results by investigating into the code. The exploratory study has resulted into identification of several code smells that have a negative

2 impact on the classes including some of the code smells that are not listed. We propose a refactoring solution for the code smells identified that improves the readability improves code design as well efficiency by eliminating unnecessary conditionings. II. CASE STUDY Our thesis started with a study of an industrial code related to financials domain. Focused area was calculation module that is responsible for all sort of calculations related to accruals, Arrears, rental and amortization calculations. A. Understaning the Domain Prior to start identification of bad smells [8] the objective was to understand the domain by Top down and bottom up approach [17]. We has several sessions with the domain experts and mean while also understand things by code scraping and web content. B. Identification of Code Smells and there Mitigation The calculation module was modified and altered by number of resources due nature of clients, requirement change and domain complexity. As the application evolved it has compromised on design and code quality. Initially we started identification of code smells using automated tools like CCFinder [24] and PBCA[23]. CC Finder is a tool to find duplicate code. It uses token based clone-detecting technique and the metrics [19]. Looking into the CCFinder, PCBA reports and code scraping combination of anti-pattern found was Spaghetti Code and God Class [3-5]. The know code smells illustrated by Folwer [3] found in code were Duplicate Code Large Class Long Method Long parameter List Type Codes Temporary Field Conditional Complexity C. Refactoring Techinques Respective refactoring techniques can be utilized to remove these code smells [5]. For example, Duplicate Code can be removed by Extract Method, Pull-up Field, Form Template Method Extract Class [3]. Similarly, Extract Method, Replace Temp with Query, Introduce Parameter Object, Preserve Whole Object, Replace Method with Method Object, Decompose Conditional for Long Method. Conditional Complexity could be removed by Replace Parameter with Method, Preserve Whole Object, or Introduce Parameter Object [3]. III. RELATED WORK Significant amount of research has been done in field of Code understanding, Identification of Code smell and refactoring. Several approaches for understanding Code have been devised to decrease or at least maintain the cost of understanding the software. Different approaches include Code Understanding Theory, Data-centered versus Control-centered, Code Understanding and Tools [17]. A major contribution in field of identification of code smell and refactoring techniques has been added by Martin Fowler [3][5][8] that has been further extended by K.Bent [8], Riel and Demeyer. Riel has major contribution in identification of antipatterns in the software design. Another major contribution of A.J Riel to object oriented design and refactoring is object- Oriented Design Heuristics [26]. OOD Heuristics are basically are the pattern and practices and experience of the author to improve object oriented design. Serge Demeyer [27] provided a literature in order to guide on how to reverse engineer legacy systems, understand their problems, and then reengineer those systems to meet new demands. Patterns have been used to clarify and explain the process of understanding large code bases, hence transforming them to meet new requirements. Several Methodology and research work has been published for identification of Code Smells that can be categorized as Detection based on lexical analysis [18,19] Detection based on source code metrics [20], Detection based on an abstract syntax tree representation of the system [21], Detection based on isomorphic program dependence graphs [22]. Lientz, Swanson & Tompkins [28] did a study, where they surveyed 69 system and department managers from as many organizations on maintenance effort and activities. Overall, they found the distribution of the maintenance activity to be 18.2 % adaptive, 17.4% corrective, 60.3% perfective and 4.1% other [28]. Current researches include metrics based refactoring which helps in identifying areas to be focused for refactoring. Several tools have been developed for code smells identification and guidance [29-30][23]. Some tools with automated refactoring have also been created. IV. CODE SMELLS AND REFACTORING Although, different authors have provided a list of various code smells, however we have discovered some code smells in this study which has not been provided in the current literature. We list them in this section. Despite of the code smells identified by Fowler we found some patterns that could be refined by refactoring. We believe that these patterns are quite often found in industrial code related to financial applications. Thereby these can be improved by applying the appropriate suggested refactoring technique.

3 A. Branching in a Loop It has been observed in the code that in loop there is sometimes a different logic for the first iteration of loop and different for rest of the iteration, same as it can be seen in the code snippet added below. The branch statement is executed for each iteration unnecessarily. Code Smell Pattern FOR counter = 0 TO maxcount rentalamount[counter + 1] = (period - counter) * Amount IF counter = 0 THEN principalamount[counter + 1] = financedamount - principalamount[counter + 1] ELSE principalamount[counter + 1] = principalamount[counter] - principalamount [counter + 1] END IF NEXT Figure 1. Code smell Branching in a loop In the above code we can see a loop starting from counter 0 to maxcount where maxcount is variable holding value for loop iteration count. The above code basically calculates the rental amount and principal amount for each period. principalamount, FinancedAmount are array of size n where n is number of periods in selected case. It can be observed from the above code snippet Figure 1 that there is different calculation for the first iteration of the code that principalamount[counter + 1] = financedamount - principalamount[counter + 1] is executed only as it is places in a condition where counter is zero. And principalamount[counter + 1] = principalamount[counter] - principalamount [counter + 1] is executed for rest of the iteration. Refactoring This situation can be avoided by simply executing the task of first iteration prior to the execution of the loop. Look into the Figure 2 containing refactored code. The code for the first iteration is placed before the loop that is only focused for the iteration where counter in 0. principalamount[1] = financedamount - principalamount[1] rentalamount[ 1] = (period) * Amount FOR counter = 1 TO maxcount rentalamount[counter + 1] = (period - counter) * Amount principalamount[counter + 1] = principalamount[counter] - principalamount [counter + 1] NEXT Figure 2. Refactoring Branching in a loop The loop is now executed from index 1 instead of 0, as the iteration 0 has been fetched and executed before the loop. Comparing the code in Figure 1 and Figure 2 we can see that Conditioning for index 0 has been removed that has resulted in reducing the complexity of the algorithm by o(n-1). B. Standardzining equations to Eliminate Conditioning It has been observed in some of the cases that the equations can be standardized instead of applying branching into the cases. Look into the code snippet in Figure 3 Code Smell Pattern IF frequency = 4 THEN interst_rate =Truncate((EXP(LOG interst_rate /100 +1)/(1*4))-1)*(1*4), 10) ELSEIF frequency = 1 THEN interst_rate=truncate((exp(log(interst_rate/100 +1)/(1*1))-1)*(1*1), 10) ELSEIF frequency = 2 THEN interst_rate =truncate((exp(log(interst_rate/100 +1)/(1*2))-1)*(1*2), 10) END IF Figure 3. Code Smell for Standardizing Equaiton The above code calculates an interest rate in a financial application based on the frequency period selected. Refactoring By observing the pattern in figure 3 we can analyze the equations in the conditioning statements the pattern is similar except that equation is directly dependent on the frequency of the statement thereby the formula could be simplified to the formula mentioned in Figure 4. By creating generalized formula for this type of case we can now eliminate branch conditioning. interst_rate =Truncate((EXP(LOG(interst_rate/100 +1)/(1*frequency))-1)*(1* frequency), 10) Figure 4. Refactored Code after Standardizing Equaiton

4 C. Replace Conditioning by Matrix Data Structure Another pattern analyzed and repeatedly found in industrial code is nested branching. Use of if within another if can be quite expensive especially if it is also nested within a loop. Have a look into the code snippet below. There is type code Frequency that has several dependent variables on it like interval, divisor, frequency and period, And these value may be constant throughout the application domain hence can be stored at a common location. Code Smell Pattern IF frequncytypecode = '00001' THEN interval = 1 ELSEIF frequncytypecode = '00002' THEN IF mod(period, 3) <> 0 THEN RETURN -2 period = period / 3 interval = 3 ELSEIF frequncytypecode = '00004' THEN IF mod(period, 6) <> 0 THEN RETURN -3 period = period / 6 interval = 6 ELSEIF frequncytypecode = '00003' THEN IF mod(period, 12) <> 0 THEN RETURN -4 period = period / 12 interval = 12 END IF Refactoring Figure 5. Code Smell for Data Centric Conditioning To handle the above pattern we suggest combination of changes. Primarily we suggest a data structure that would be responsible to hold common dependent variable values i.e. in interval, Divisor and frequency. Secondly, to remove nested if statements we present a data structure that need to be populated once throughout the application life and can be reused as key value pair. The data table is created for the formula like period = period / frequency once the application is executed as shown in Figure 6. Now whenever a clients need to access a value what it need is to get the global structure and obtain the value from the object where are period value can be obtained by simply passing the type code and period to it. Frq\ Month Figure 6. Data Table Pattern for One time Values The case IF mod(period, 3) <> 0 THEN RETURN -2 period = period / 3 can be handled by accessing value from data table populated as illustrated above. To obtain the value from the data table we just need a FrequencyTypeCode and Period. Code snippet looks like perioddatatable [<period>][<typecode>] e.g. period = perioddatatable[12] [ 0001 ] Figure 7. Data Table Pattern for One time Values Using the suggested refactoring approach we can achieve reduced Line of code, reduced conditional complexity and ease of access. V. DISCUSSION After more than five month code analysis and identification of code smell lot of code short comings were found that could be removed by refactoring. For our analysis we conducted a show case refactoring. During the refactoring process things we learned from the exercise are 1. Refactoring is harder apply as expected 2. Its time consuming 3. Restructuring of software design is quite doubtful sometimes until it s clear that it would simplify the future change and its ripples or make things more worse. Purely depends on the existing design and exposure to the new design. 4. Overall code short comings are reduced We initially started refactoring of the calculation module by segregating the responsibilities from the god class to its

5 specified classes. After segregation of class with our domain knowledge and code scraping knowledge we restructured the application design by applying appropriate refactoring technique and design pattern. For our study we used two sub modules of calculation engine for matrices calculation and result comparison. We compare the results of the two sub module of calculation engine Amortization and rental calculation before and after applying refactoring technique. Metrics Before After Model 1 Class 3 Classes LOC Method Count 8 23 Avg. Method LOC Unused Variable 19 0 Inline Comments Code Comments Figure 8. Refactoring Branching in a loop From the above matrices (figure 8) you can see the software model has been improved for amortization number of classes has increased for better improve design. Line of code has been drastically reduced by applying refactoring techniques for duplicate code like extracting method and using utility methods. Method counts have increased from 8 to 23, the increase in method count depicts the standardization and segregation of responsibilities that result in more readable and understandable code. Average LOC per method has been reduced from 203 to 70 lines. The line of code per method should be lesser but it was not reduced more in our case study due to increase in complexity and dependency in calculation within code and its data structures. Moreover there were number of unused variables in the code that were removed and similar was the case of Inline and code Comments that were removed where ever possible. Metrics Before After Model 1 Class 3 Classes LOC Method Count Avg. Method LOC Unused Variable 3 0 Inline Comments Code Comments Figure 9. Refactoring Branching in a loop Similarly, the metrics for rent calculation module can be analyzed in figure 9. The above metrics prove that refactoring the code and eliminating code smells always result into better software design. VI. CONCLUSION In this paper, we reported an exploratory study, analyzed the code several times for the identification of the code smells we found hundreds of code smells which provides empirical evidence of the negative impact of code smells on classes due to intensive change in code. This case study supports the inference in the literature that smells may have a negative impact on software evolution. The study also provides evidence to practitioners that they should pay more attention to systems with a high occurrence of smells during development and maintenance [25]. Systems that are changing repeatedly contains a high number of code smells therefore, the cost-of-ownership of such systems will be higher than for other systems, because developers will have to put more effort. ACKNOWLEDGMENT I sincerely thank Dr. Usman Bhatti, Asst. Professor National University of Computer and Emerging Sciences, who initially put forth the idea of writing this thesis. This thesis is result of his initiative and constant motivation. The great inspiration and constant encouragement from Dr. Usman is highly acknowledged. The completion of this thesis could not have been possible without my Parents support and prayers. REFERENCES [1] C. Gopalan, Refactoring Techniques in PB, SYS-CON Media, In September 11, Available: [Accessed: Dec. 5, 2009] [2] N.C. Mendonga, P.H.M. Maia, L.A. Fonseca, R.M.C. Andrade, RefaX: a refactoring framework based on XML Authors, Software Maintenance, Proceedings. 20th IEEE International Conference on. 11/10/2004; DOI: /ICSM [3] F. Martin. Refactoring. Canada: Addison-Wesley. ISBN [4] W.F. Opdyke,. Refactoring Object-Oriented Frameworks, University of Illinois at Urbana-Champaign, Year [5] F. Martin, Etymology Of Refactoring, In September 10, Available: [Accessed: Jan. 3, 2010] [6] Code refactoring, Wikipedia.com, Available: [Accessed: Jan. 13, 2010] [7] R. C. Martin, "Refactoring," in Title: Agile Software Development, Principles, Patterns, and Practices, 1st Edition. Publisher: Edition Prentice Hall, October 15, 2002, pp. inclusive page numbers [8] M. Fowler and K. Beck, "Bad Smells in Code," in Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000, pp [9] PowerBuilder, Wikipedia.com, Available: [Accessed: Jan. 13, 2010] [10] PowerBuilder A rich Application Development Tool, Sybase, Available:

6 [Accessed: December. 05, 2009] [11] Emerson Murphy-Hill, A. P. Black, "Refactoring Tools: Fitness for Purpose," IEEE Software, vol. 25, no. 5, pp , Sep./Oct. 2008, doi: /ms [12] W. Kadir and P. Loucopoulos. Relating evolving business rules to software design. In Int. Conf. on Software Engineering and Practice (SERP), volume 1, pages , Las Vegas, NV, June CSREA Press [13] M. Lehman. The programming process. Technical Report RC2722, IBM Research Centre, Yorktown Heights, NY, Sept [14] M. Lehman. Software evolution threat and challenge. Professorial and Jubilee Lecture, Oct th international Stevens Award, hosted by ICSM [15] M. Pizka, Straightening Spaghetti-Code with Refactoring?, In Proceedings of the Int. Conf. on Software Engineering Research and Practice SERP, 2004 [16] Software Design, Wikipedia.com, Available: [Accessed: Jan. 20, 2010] [17] H. Yang, P. Luker, W. C. Chu, "Code Understanding through Program Transformation for Reusable Component Identification," wpc, pp.148, 5th International Workshop on Program Comprehension (WPC '97), 1997 [18] B. S. Baker. A Program for Identifying Duplicated Code. Computing Science and Statistics, 24:49 57, [19] T. Kamiya, S.i Kusumoto, and K. Inoue. Ccfinder: A MultilinguisticToken-based Code Clone Detection System for Large Scale Source Code. IEEE Trans. Softw. Eng., 28(7): , [20] J. Mayrand, C. Leblanc, and E. Merlo. Experiment on the Automatic Detection of Function Clones in a Software System Using Metrics. In ICSM 96: Proceeding of the 1996 International Conference on Software Maintenance, page 244, Washington, DC USA, IEEE Computer Society. [21] I. D. Baxter, A. Yahin, L. Moura, Marcelo Sant Anna, and Lorraine Bier. Clone Detection Using Abstract Syntax Trees. In ICSM 98: Proceedings of the InternationalConference on Software Maintenance, page 368, Washington, DC, USA, IEEE Computer Society. [22] J. Krinke. Identifying Similar Code with Program Dependence Graphs. In WCRE 01: Proceedings of the Eighth Working Conference on Reverse Engineering (WCRE 01), page 301, Washington, DC, USA, IEEE Computer Society. [23] PB Code Analyzer, Ecocion.com, Available: [Accessed: Feb. 21, 2010] [24] CC Finder Official Site, CCFinder.net, Available: [Accessed: Dec. 20, 2009] [25] F. Khomh, M. D. Penta, Y. Gueheneuc An Exploratory Study of the Impact of Code Smells on Software Change-proneness, Proceedings of the th Working Conference on Reverse Engineering; Year 2009; Pages: [26] A.J Riel, Object-Oriented Design Heuristics, 1st edition, Year: 1996; ISBN: X [27] S. Demeyer, S. Ducasse, O. Nierstrasz; Object-Oriented Reengineering Patterns; Publisher: Morgan Kaufmann; 1st edition; Published 2002; ISBN-13: [28] S.R. Schach, B.Jin, G.Z. Heller; Determining the Distribution of Maintenance Categories: Survey versus Empirical Study; Volume 8, Issue 4; Year: 2003 [29] D.Binkley, M. Ceccato, Mark Harman, F. Ricca, Paolo Tonella, "Tool- Supported Refactoring of Existing Object-Oriented Code into Aspects," IEEE Transactions on Software Engineering, vol. 32, no. 9, pp , Sept. 2006, doi: /tse [30] Herbold, S. Grabowski, J. Neukirchen Automated Refactoring Suggestions Using the Results of Code Analysis Tools; Advances in System Testing and Validation Lifecycle, VALID '09. First International Conference on Issue Date: Sept Page(s):