Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

The art of improving the design of existing code

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. Refactoring The art of improving the design of existing code
  2. 2. TDD circle of life Test fails Testpasses Refactor
  3. 3. What is refactoring? ✤ Refactoring does not include just any changes in a system (features) ✤ Refactoring is not rewriting from scratch ✤ Refactoring is not just any restructuring intended to improve code ✤ Refactoring changes the balance point between up-front design and emergent design ✤ Refactoring can be small or large
  4. 4. OK, we want to refactor! But… ✤ Why to refactor? ✤ What to refactor? ✤ How to refactor?
  5. 5. Why? Because refactored code is easier to understand and cheaper to modify ✤ Clean code ✤ Better code
  6. 6. What? How can we identify the candidate code to refactor? Intuition? We need better tools than intuition… => We can relay on design smells
  7. 7. How? Ok, candidate code has been identified How to improve that code? Intuition? No, we need proven tools to improve that code => We can relay on refactoring
  8. 8. Design smells Smells are problems Smells are warning signs about potential problems in code A design smell is a symptom Smells are violation of principles: SOLID principles
  9. 9. Symptoms of rotting design
  10. 10. Symptoms of rotting design (1/7) Rigidity Software tends to be difficult to change
  11. 11. Symptoms of rotting design (2/7) Fragility Software tends to break whenever changes are made
  12. 12. Symptoms of rotting design (3/7) Viscosity It is harder to make changes using methods that preserve design, and easier to use methods that does not preserve design, such as hacks
  13. 13. Symptoms of rotting design (4/7) Immobility It is difficult to reuse software parts
  14. 14. Symptoms of rotting design (5/7) Needless complexity Overdesign
  15. 15. Symptoms of rotting design (6/7) Needless repetition Cut & paste, updating structures that could be unified under a single abstraction, DRY
  16. 16. Symptoms of rotting design (7/7) Opacity Software tends to be difficult to understand code written in a clear and expressive manner vs code that is written in a opaque and convolute manner
  17. 17. Refactoring circle While smells remain: 1. Choose the worst smell 2. Select a refactoring that will address the smell 3. Apply the refactoring Choose worst sm ell Selectrefactoring Apply refactor
  18. 18. Design smells taxonomy ✤ Bloaters ✤ Object-Orientation Abusers ✤ Change Preventers ✤ Dispensables ✤ Couplers
  19. 19. Bloaters Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. Usually these smells do not crop up right away, rather they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).
  20. 20. Bloaters ✤ Long method ✤ Large class ✤ Long parameter list ✤ Primitive obsession ✤ Data clumps
  21. 21. Long method A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions
  22. 22. Large class A class contains many fields/methods/lines of code
  23. 23. Long parameter list More than three or four parameters for a method.
  24. 24. Primitive obsession ✤ Use of primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.) ✤ Use of constants for coding information (such as a constant USER_ADMIN_ROLE = 1 for referring to users with administrator rights.) ✤ Use of string constants as field names for use in data arrays.
  25. 25. Data clumps Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database). These clumps should be turned into their own classes
  26. 26. Object- Orientation Abusers All these smells are incomplete or incorrect application of object-oriented programming principles.
  27. 27. Object-Orientation Abusers ✤ Switch statements ✤ Refused bequest ✤ Temporary field ✤ Alternative classes with different interfaces
  28. 28. Switch statements You have a complex switch operator or sequence of if statements.
  29. 29. Refused bequest If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off- kilter. The unneeded methods may simply go unused or be redefined and give off exceptions
  30. 30. Temporary field Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they are empty
  31. 31. Alternative classes with different interface Two classes perform identical functions but have different method names
  32. 32. Change preventers These smells mean that if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more complicated and expensive as a result
  33. 33. Change preventers ✤ Divergent change ✤ Parallel inheritance hierarchies ✤ Shotgun surgery
  34. 34. Divergent change You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products
  35. 35. Parallel inheritance hierarchies Whenever you create a subclass for a class, you find yourself needing to create a subclass for another class.
  36. 36. Shotgun surgery Making any modifications requires that you make many small changes to many different classes.
  37. 37. Dispensables A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand
  38. 38. Dispensables ✤ Comments ✤ Duplicate code ✤ Lazy class ✤ Data class ✤ Dead code ✤ Speculative generality
  39. 39. Comments A method is filled with explanatory comment
  40. 40. Duplicated code Two code fragments look almost identical
  41. 41. Lazy class Understanding and maintaining classes always costs time and money. So if a class doesn't do enough to earn your attention, it should be deleted
  42. 42. Data class A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters). These are simply containers for data used by other classes. These classes do not contain any additional functionality and cannot independently operate on the data that they own.
  43. 43. Dead code A variable, parameter, field, method or class is no longer used (usually because it is obsolete)
  44. 44. Speculative generality There is an unused class, method, field or parameter
  45. 45. Couplers All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation
  46. 46. Couplers ✤ Feature envy ✤ Inappropriate intimacy ✤ Message chains ✤ Middle man ✤ Incomplete library class
  47. 47. Feature envy A method accesses the data of another object more than its own data
  48. 48. Inappropriate intimacy One class uses the internal fields and methods of another class.
  49. 49. Message chains In code you see a series of calls resembling: $a->b()->c()->d()
  50. 50. Middle man If a class performs only one action, delegating work to another class, why does it exist at all?
  51. 51. Incomplete library class Sooner or later, libraries stop meeting user needs. The only solution to the problem – changing the library – is often impossible since the library is read-only
  52. 52. Questions?
  53. 53. Bibliography: M. Fowler, Refactoring: Improving the Design of Existing Code, Canada: Addison-Wesley, 2000 W.C. Wake, Refactoring Workbook, Addison Wesley, 2003 Images:
  54. 54. Zankiu!