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

4. CS352 – Software Engineering IILecture 13: SW QA - Refactoring Based on Refactoring Book By Martin Fowler && CC2e Ch on Refactoring http://www.acadox.com/join/24VZEM http://www.acadox.com/class/3962

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

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

7. 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

8. 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

10. 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.

11. 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.

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

13. 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

14. 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

15. 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.

16. 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

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

18. 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.

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

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

22. Code Bad Smells • code is duplicated • a method is toolong • a loop is too long or too deeply nested • class has poorcohesion • class interface does not provide consistent level of abstraction • parameter list has too many parameters • changes within a class are compartmentalized • change requires parallel modifications in multiple classes • inheritance hierarchies must be modified in parallel

23. More Code Smells • case statements modified in parallel • related data not organized into classes • method uses more features of another class than its own • primitive data type is “overloaded” • class does not too very much • chain of methods passes “tramp data” • middleman object doing nothing • class relies on internals of another • method has a poor name • public data members/fields

24. and Even More Code Smells • subclass uses only small parts of its parent’s methods • comments explain too complex code • use of global variables • method must use complex setup code before and/or takedown code after calling another method • code not needed now, but maybe in the future

26. Types of Refactorings (CC2e) • Data level refactorings • Statement-level refactoring • Method-level refactoring • Class implementation refactoring • Class interface refactoring • System-level refactorings

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

28. 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

29. Statement-level refactoring • decompose boolean expression • replace complex boolean exp. with well-named method • consolidate code fragments of different parts of conditional statement • Use break/continue/return in loops • Return/break early • use polymorphism instead of switch • use “null” objects

30. 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

31. more Method-level refactoring • separate query from modification • combine similar methods by parameterization • separate methods • pass one whole object instead of many specific fields (cf “Addressee”) • pass specific fields instead of object • encapsulate downcasting

32. 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 specialised code into subclass • combine similar code into superclass

33. Class Interface 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

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

35. System-level Refactorings • create reference source for data outside your control • change bi-directional class association to uni-directional • change uni-directional class association to bi-directional • Provide factory method instead of a constructor • replace error code with exceptions and v.v.