CS352 – Software Engineering II Lecture 21: SW QA - Refactoring

4. CS352 – Software Engineering IILecture 21: SW QA - Refactoring Based on Refactoring Book By Martin Fowler && CC2e Ch on Refactoring

5. حديث شريف • إن الله يحب إذا عمل أحدكم عملا أن يتقنه • إن الله كتب الإحسان على كل شئ

6. Course Contents We will cover as much of these as we can: • Design and design patterns 35% • Introduction to Design (3~4 wks) • Software Architecture • Design Principles • Design Patterns • Design QA & Evaluation

7. Course Contents We will cover as much of these as we can: • Quality Assurance and Testing 40% • Overview of QA in SE (4 wks) • Reviews • Refactoring • Unit and Integration Testing • Configuration Managment

8. Course Contents We will cover as much of these as we can: • Cloud Deployment / PM 25% • Cloud Models (2-3 wks) • RESTful Architecture • Google App Engine • Managing SW Projects • Scrum

9. Outline • Importance of Refactoring • Code Smells • Refactoring Catalog • Example

10. Change and Configuration Management Software Quality Landscape Reviews Collaborative Development / Reviews Requirements V & V Guidelines, Standards and Templates Design Review Bug Tracking Surveys Contract Review QA Planning and Budgeting Testing Metrics Debugging Refactoring Deployment & Maintenance Planning Design Testing Requirements Development M a n a g e m e n t

11. Change and Configuration Management Software Quality Landscape Reviews Collaborative Development / Reviews Requirements V & V Guidelines, Standards and Templates Design Review Bug Tracking Surveys Contract Review Refactoring QA Planning and Budgeting Testing Metrics Debugging Deployment & Maintenance Planning Design Testing Requirements Development M a n a g e m e n t

13. You write code that tells the computer what to do, and it responds by doing exactly what you tell it. Our code = • The trouble is that when you are trying to get the program to work, you are not thinking about that future developer.

14. What happens when future developer comes ? • Someone will try to read your code in a few months' time to make some changes. The programmer will take a week to make a change that would have taken only an hour if she had understood your code.

15. Solution to the spaghetti code problem • This is called Refactoring • Any fool can write code that a computer can understand. Goodprogrammers write code that humans can understand.

16. Refactoring Definition • “Change to the internalstructure of software to make it easier to understand and cheaper to change, WITHOUTchanging the observable behaviour” (Martin Fowler, 1999) • I.e. changes “inside the black box” only

17. Refactoring Definition • “Change to the internal structure of software to make it easier to understand and cheaper to change, WITHOUT changing the observable behaviour” (Martin Fowler, 1999) • I.e. changes “inside the black box” only

18. Refactoring Definition • Refactoring (noun): achange made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. • Refactor (verb): torestructure software by applying a series of refactorings without changing its observable behavior.

19. Key Points • Program changes are a fact of life • Change => degrade or improve • “code smells” indicate need for change • Know different refactorings (esp. IDE support …) • Use safe strategy • Do it early on

20. Why Refactor? • Refactoring makes program understandable • Refactoring makes program maintainable. • Refactoring helps you find bugs • Refactoring makes you program faster

21. When to Refactor? • Should we allocate 2 weeks every 3 months to refactoring? • M.F: Refactoring is something you do all the time in little bursts. • You don't decide to refactor, • you refactor because you want to do something else, • and refactoring helps you do that other thing.

22. When to Refactor? • Refactor when you add function • Refactor when you need to fix a bug • Refactor as you do code review

23. Bad Smells in Code • Duplicated code • Long Method • Large Class • Long Parameter List Possible Refactorings ExtractMethod ExtractClass Send Whole Object

25. CC2nd: Code Bad Smells • code is duplicated • a method is toolong • a loop is too long or too deeply nested • class has poorcohesion • parameter list has too many parameters • changes within a class are compartmentalized • change requires parallel modifications in classes

26. CC2nd: More Code Smells • related data not organized into classes • method uses more features of another class than its own • class does not do very much • middleman object doing nothing • class relies on internals of another • method has a poor name • public data members/fields

27. CC2nd: Even More Code Smells • subclass uses only small parts of its parent’s methods • comments explaintoo complex code • use of global variables • code not needed now, but maybe in the future

29. CC2nd: Types of Refactorings • Data level refactorings • Statement-level refactoring • Method-level refactoring • Class implementation refactoring • Class interface refactoring • System-level refactorings

30. CC2nd: Data-level Refactorings • Replace magic number with named constant • Rename variable to clearer informative name • Replace expression with method call • Introduce intermediate variable • Replace multi-use variable with single-use variables

31. CC2nd: More Data-level Refactorings • Use local variable instead of parameter (use final in parameter list) • convert primitive data to class • convert type codes to enumeration • or to class with sub-classes • change array to an object • encapsulate collection

32. CC2nd: Statement-level refactoring • decompose boolean expression • replace complex boolean exp. with well-named method • Use break/continue/return in loops • Return/break early • use polymorphism instead of switch • use “null” objects

33. CC2nd: Method-level refactoring • extract a method • move method call inline • turn a long routine into a class • replace complex algorithm with a simple one • add a parameter • remove a parameter

34. CC2nd: more Method-level refactoring • combine similar methods by parameterization • separate methods • pass one whole object instead of many specific fields (cf “Addressee”) • pass specific fields instead of object

35. CC2nd: Class Implementation Refactoring • change value object to reference object • change reference object to value object • replace method with data initialization • change member data or method placement • extract specialized code into subclass • combine similar code into superclass

36. CC2nd: ClassInterface Refactoring • move method into another class • split class into two • remove a class • hide a delegate • remove a middleman • replace inheritance by composition • replace composition by inheritance • introduce “foreign” method • introduce extension class

37. CC2nd: more Class Interface Refactoring • encapsulate exposed data fields • remove unwanted set methods • hide methods that are intended for use outside a class • collapse sub with superclass if very similar

38. CC2nd: System-level Refactorings • Change bi-directional class association to uni-directional • Change uni-directional class association to bi-directional • Refactor to design patterns • Replace error code with exceptions and v.v.

39. Excellent Resources • https://sourcemaking.com/refactoring/ • http://refactoring.com/catalog/ • https://refactoring.guru/