Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Software Craftsmanship
Code Smells
Software Craftsmanship Manifesto
“Not only working software, but also well-
crafted software
Not only responding to change...
Technical Debt
Software Finance
Skipping (or deferring) design Borrowing money
Refactoring (i.e. behavior-preserving
desig...
Code Smells
• Lost Intent
• Inefficient Name
• Duplicated Code
• Deodorant Comment
• Long Method
• Large Class
• Lazy Clas...
Lost Intent
Just as a traffic sign may be obscured by shrubs, Code that doesn't easily communicate
it's author's intention...
Lost Intent
Intention-Revealing Code Lost Intent
The purpose of the code is clear.
Low-level or complex logic obscures
the...
Lost Intent
Inefficient Name
Where The Streets Have No Name
Inefficient Name
tmp = finder.fetch("0182901");
Account theAccount = finder.fetch(transaction.getSource());
account = find...
Duplicated Code
If you see the same code structure in more than one place, you can be sure that your program
will be bette...
Duplicated Code
Deodorant Comment
Comments often are used as a deodorant.
— Refactoring [page 87], Martin Fowler and Kent Beck
Deodorant Comment
Comment Guidelines
• Whenever possible make your code express
the intent of the comment and remove the
comment.
• Comments...
Long Method
A long method is too much to digest
Long Method
Large Class
Take on too many responsibilities
Large Class
WebServicesProviderContoller
• performValidationCB()
• executeBusinessProcessCB()
Lazy Class
A lazy class isn't doing enough to justify its existence.
Lazy Class
Lazy Class
Employee constructor
.
Passing Jobs in
Employee
constructor.
Oddball Solution
When a problem is solved one way throughout a system and the same problem is
solved another way in the sa...
Oddball Solution
Primitive Obsession
Primitive Obsession exists when code solves a problem using a tool that's too simplistic.
Primitive Obsession
Switch Statement
Most times you see a switch statement you should consider polymorphism.
— Refactoring, Martin Fowler and ...
Switch Statement
Move each leg of the conditional to an overriding method in a subclass. Make the original
method abstract.
Switch Statement
• Not every occurrence of a switch statement
(or if...else if...else if... statements) should be
replaced...
Speculative Generality
You get this smell when people say "Oh, I think we will need the ability to do that someday"
and th...
Speculative Generality
Long Parameter List
Methods that take too many parameters produce client code that is awkward and
difficult to work with.
Long Parameter List
user = userManager.create(USER_NAME, group, USER_NAME, “test",
USER_NAME, LANGUAGE, false, false, new ...
Conditional Complexity
Conditional logic is innocent in its infancy, when it is simple to understand and contained
within ...
Conditional Complexity
Combinatorial Explosion
When new combinations of data or behavior further bloat an already bloated design, you've got
a Co...
Combinatorial Explosion
Alternative Classes With Different
Interfaces
This subtle smell results when differences in the interfaces of similar clas...
Alternative Classes With Different
Interfaces
Inappropriate Intimacy
Sometimes classes become far too intimate and spend too much time delving in each others'
private p...
Inappropriate Intimacy
Indecent Exposure
We don't normally expose wires inside a wall or ceiling.
Indecent Exposure
Refused Bequest
Subclasses get to inherit the methods and data of their parents. But what if they don't
want or need what ...
Refused Bequest
Black Sheep
Black Sheep
Solution Sprawl
When code and/or data used to perform a responsibility becomes sprawled across numerous
classes, Solution ...
Solution Sprawl
Feature Envy
Feature Envy
Temporary Field
An object's field (a.k.a. instance variable) should have meaning during the full lifetime
of the object.
Temporary Field
Side Effect
Side Effect
References
• Refactoring: Improving the Design of Existing
Code by Martin Fowler
• Refactoring to Patterns by Joshua Kerie...
Nächste SlideShare
Wird geladen in …5
×

Code Smells

2.589 Aufrufe

Veröffentlicht am

Software Craftsmanship: smells in code

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Code Smells

  1. 1. Software Craftsmanship Code Smells
  2. 2. Software Craftsmanship Manifesto “Not only working software, but also well- crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships”
  3. 3. Technical Debt Software Finance Skipping (or deferring) design Borrowing money Refactoring (i.e. behavior-preserving design improvements) Repaying principal Slower development due to code smells Paying interest
  4. 4. Code Smells • Lost Intent • Inefficient Name • Duplicated Code • Deodorant Comment • Long Method • Large Class • Lazy Class More…
  5. 5. Lost Intent Just as a traffic sign may be obscured by shrubs, Code that doesn't easily communicate it's author's intention is hazardous: hard to understand, extend and modify.
  6. 6. Lost Intent Intention-Revealing Code Lost Intent The purpose of the code is clear. Low-level or complex logic obscures the code's purpose. You can easily find the code you seek. The location of code makes little sense. Every step of an algorithm is clearly defined. The steps of the algorithm are blended together.
  7. 7. Lost Intent
  8. 8. Inefficient Name Where The Streets Have No Name
  9. 9. Inefficient Name tmp = finder.fetch("0182901"); Account theAccount = finder.fetch(transaction.getSource()); account = finder.fetch( new StateMatcher("VA") ); for(Account item : finder.fetchAll()) { … } getDrctn() getDir() getDirection() These are five lines chosen at random from a class. Each is grabbing a fetch result and putting it in a variable of type Account.
  10. 10. Duplicated Code If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them. — Refactoring[page 76], Martin Fowler and Kent Beck
  11. 11. Duplicated Code
  12. 12. Deodorant Comment Comments often are used as a deodorant. — Refactoring [page 87], Martin Fowler and Kent Beck
  13. 13. Deodorant Comment
  14. 14. Comment Guidelines • Whenever possible make your code express the intent of the comment and remove the comment. • Comments are to provide intent that is not expressible in code. • Any comment that duplicates what the code says should be deleted.
  15. 15. Long Method A long method is too much to digest
  16. 16. Long Method
  17. 17. Large Class Take on too many responsibilities
  18. 18. Large Class WebServicesProviderContoller • performValidationCB() • executeBusinessProcessCB()
  19. 19. Lazy Class A lazy class isn't doing enough to justify its existence.
  20. 20. Lazy Class
  21. 21. Lazy Class Employee constructor . Passing Jobs in Employee constructor.
  22. 22. Oddball Solution When a problem is solved one way throughout a system and the same problem is solved another way in the same system, one of the solutions is the oddball or inconsistent solution.
  23. 23. Oddball Solution
  24. 24. Primitive Obsession Primitive Obsession exists when code solves a problem using a tool that's too simplistic.
  25. 25. Primitive Obsession
  26. 26. Switch Statement Most times you see a switch statement you should consider polymorphism. — Refactoring, Martin Fowler and Kent Beck (page 82).
  27. 27. Switch Statement Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.
  28. 28. Switch Statement • Not every occurrence of a switch statement (or if...else if...else if... statements) should be replaced with a polymorphic solution.
  29. 29. Speculative Generality You get this smell when people say "Oh, I think we will need the ability to do that someday" and thus want all sorts of hooks and special cases to handle things that aren't required. — Refactoring, Martin Fowler and Kent Beck (page 83).
  30. 30. Speculative Generality
  31. 31. Long Parameter List Methods that take too many parameters produce client code that is awkward and difficult to work with.
  32. 32. Long Parameter List user = userManager.create(USER_NAME, group, USER_NAME, “test", USER_NAME, LANGUAGE, false, false, new Date(), "blah", new Date());
  33. 33. Conditional Complexity Conditional logic is innocent in its infancy, when it is simple to understand and contained within a few lines of code. Unfortunately, it rarely ages well. — Joshua Kerievsky, Refactoring to Patterns, page 41.
  34. 34. Conditional Complexity
  35. 35. Combinatorial Explosion When new combinations of data or behavior further bloat an already bloated design, you've got a Combinatorial Explosion smell.
  36. 36. Combinatorial Explosion
  37. 37. Alternative Classes With Different Interfaces This subtle smell results when differences in the interfaces of similar classes leads to duplicated code.
  38. 38. Alternative Classes With Different Interfaces
  39. 39. Inappropriate Intimacy Sometimes classes become far too intimate and spend too much time delving in each others' private parts. — Refactoring [page 85], Fowler and Beck
  40. 40. Inappropriate Intimacy
  41. 41. Indecent Exposure We don't normally expose wires inside a wall or ceiling.
  42. 42. Indecent Exposure
  43. 43. Refused Bequest Subclasses get to inherit the methods and data of their parents. But what if they don't want or need what they are given? — Refactoring[page 87], Martin Fowler and Kent Beck
  44. 44. Refused Bequest
  45. 45. Black Sheep
  46. 46. Black Sheep
  47. 47. Solution Sprawl When code and/or data used to perform a responsibility becomes sprawled across numerous classes, Solution Sprawl is in the air. — Joshua Kerievsky, Refactoring to Patterns, page 43.
  48. 48. Solution Sprawl
  49. 49. Feature Envy
  50. 50. Feature Envy
  51. 51. Temporary Field An object's field (a.k.a. instance variable) should have meaning during the full lifetime of the object.
  52. 52. Temporary Field
  53. 53. Side Effect
  54. 54. Side Effect
  55. 55. References • Refactoring: Improving the Design of Existing Code by Martin Fowler • Refactoring to Patterns by Joshua Kerievsky. • https://elearning.industriallogic.com/gh/subm it?Action=AlbumContentsAction&album=reco gnizingSmells&devLanguage=Java

×