1 / 35

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

CS352 – Software Engineering II Lecture 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. حديث شريف. إن الله يحب إذا عمل أحدكم عملا أن يتقنه إن الله كتب الإحسان على كل شئ.

ceceliap
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related