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.
RediscoveringModularityChris ChedgeyStructure101@chedgeyStuttgart, Munich, NurembergNovember 20th – 22nd 2012
ModularityManage complexity       byEncapsulation
Information hiding  Modularity  Manage complexity         by  Encapsulation
Information hidingDefined interface                Modularity                Manage complexity                       by   ...
Information hidingDefined interface                                 Clear responsibility                Modularity        ...
Information hidingDefined interface                                 Clear responsibility                Modularity        ...
Information hidingDefined interface                                 Clear responsibility                Modularity        ...
Information hidingDefined interface                                 Clear responsibility                Modularity        ...
Information hiding Clear responsibility Defined interface                         Coupling AbstractionEncapsulation       ...
Information hiding Clear responsibility Defined interface                         Coupling AbstractionEncapsulation       ...
Complexity             Composition
Complexity                Composition   Cyclomatic   Complexity     (CC)
(same problem)
Information hiding Clear responsibility Defined interface                         Coupling AbstractionEncapsulation       ...
Complexity                Composition   Cyclomatic   Complexity     (CC)
Complexity                CompositionCompositional Complexity   (CC)
Packages       Classes
Information hiding?Clear responsibility  Defined interface?                       Coupling? AbstractionEncapsulation      ...
Complexity                CompositionCompositional Complexity   (CC)
Complexity                CompositionCompositional Complexity       +Hierarchical   (CC)            => Scalable
Coupling
Dependencies
Dependencies
“Tangles”
=
=    Not scalable!!
Ideally…Start with a loose “architecture”
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher...
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher...
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher...
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher...
Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher...
0.7.2Mar „04
0.8.6Oct „04
0.8.7Apr „05
Erosion “Sometimes the developers manage to maintain this purity of design   through the initial development and into the ...
0.8.8May „05
1.0.0Jun „06
1.3.0Nov „07
1.3.5Sep „08
Cost…
Cost…  Miserable developers
Cost…  Miserable developers  Cost per feature increases
Cost…  Miserable developers  Cost per feature increases  Unexpected impacts of change
Cost…  Miserable developers  Cost per feature increases  Unexpected impacts of change  Unreliable schedules
Cost…  Miserable developers  Cost per feature increases  Unexpected impacts of change  Unreliable schedules  Test cycles i...
Cost…  Miserable developers  Cost per feature increases  Unexpected impacts of change  Unreliable schedules  Test cycles i...
Cost…  Miserable developers  Cost per feature increases  Unexpected impacts of change  Unreliable schedules  Test cycles i...
Technical Debt
Technical Debt
Technical Debt
Technical Debt
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Refactoring   Restructuring
Refactoring                  Restructuring•   “Changing code without   •   “Reorganizing a code-base    modifying behavior...
Refactoring                  Restructuring•   “Changing code without   •   “Reorganizing a code-base    modifying behavior...
Refactoring                          Restructuring•   “Changing code without           •   “Reorganizing a code-base    mo...
Refactoring                           Restructuring•   “Changing code without            •   “Reorganizing a code-base    ...
Retrofitting…
Retrofitting…Physical or virtual?
Retrofitting…Physical or virtual?Top-down or bottom-up?
Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tangles
Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use...
Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use...
Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use...
Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use...
Structure101
Restructure101  Structure101
Restructure101                  Structure101Visualization
Restructure101  Structure101
Architecture   •   defined, communicated, enforced Modularity    •   interfaces, responsibility  Structure    •   encapsul...
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Upcoming SlideShare
Loading in …5
×

Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012

828 views

Published on

  • Be the first to comment

  • Be the first to like this

Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012

  1. 1. RediscoveringModularityChris ChedgeyStructure101@chedgeyStuttgart, Munich, NurembergNovember 20th – 22nd 2012
  2. 2. ModularityManage complexity byEncapsulation
  3. 3. Information hiding Modularity Manage complexity by Encapsulation
  4. 4. Information hidingDefined interface Modularity Manage complexity by Encapsulation
  5. 5. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation
  6. 6. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion
  7. 7. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling
  8. 8. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling Abstraction
  9. 9. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion
  10. 10. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion Modularity
  11. 11. Complexity Composition
  12. 12. Complexity Composition Cyclomatic Complexity (CC)
  13. 13. (same problem)
  14. 14. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion Modularity
  15. 15. Complexity Composition Cyclomatic Complexity (CC)
  16. 16. Complexity CompositionCompositional Complexity (CC)
  17. 17. Packages Classes
  18. 18. Information hiding?Clear responsibility Defined interface? Coupling? AbstractionEncapsulation Cohesion Modularity?
  19. 19. Complexity CompositionCompositional Complexity (CC)
  20. 20. Complexity CompositionCompositional Complexity +Hierarchical (CC) => Scalable
  21. 21. Coupling
  22. 22. Dependencies
  23. 23. Dependencies
  24. 24. “Tangles”
  25. 25. =
  26. 26. = Not scalable!!
  27. 27. Ideally…Start with a loose “architecture”
  28. 28. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”
  29. 29. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed
  30. 30. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed(~50Kloc – Martin, Foote)
  31. 31. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed(~50Kloc – Martin, Foote)Restructure to defined architecture
  32. 32. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed(~50Kloc – Martin, Foote)Restructure to defined architectureIterate with development
  33. 33. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed(~50Kloc – Martin, Foote)Restructure to defined architectureIterate with developmentStrengthen with growth
  34. 34. 0.7.2Mar „04
  35. 35. 0.8.6Oct „04
  36. 36. 0.8.7Apr „05
  37. 37. Erosion “Sometimes the developers manage to maintain this purity of design through the initial development and into the first release. More often something goes wrong. The software starts to rot like a piece of bad meat.”Bob Martin, “Agile Software Development”
  38. 38. 0.8.8May „05
  39. 39. 1.0.0Jun „06
  40. 40. 1.3.0Nov „07
  41. 41. 1.3.5Sep „08
  42. 42. Cost…
  43. 43. Cost… Miserable developers
  44. 44. Cost… Miserable developers Cost per feature increases
  45. 45. Cost… Miserable developers Cost per feature increases Unexpected impacts of change
  46. 46. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules
  47. 47. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase
  48. 48. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less
  49. 49. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less Value of your code base declines
  50. 50. Technical Debt
  51. 51. Technical Debt
  52. 52. Technical Debt
  53. 53. Technical Debt
  54. 54. Abstraction
  55. 55. Abstraction
  56. 56. Abstraction
  57. 57. Abstraction
  58. 58. Abstraction
  59. 59. Abstraction
  60. 60. Abstraction
  61. 61. Abstraction
  62. 62. Refactoring Restructuring
  63. 63. Refactoring Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to without modifying the code to improve nonfunctional improve modularity” attributes.”
  64. 64. Refactoring Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to without modifying the code to improve nonfunctional improve modularity” attributes.” • Code-base is understandable• Code is readable
  65. 65. Refactoring Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to without modifying the code to improve nonfunctional improve modularity” attributes.” • Code-base is understandable• Code is readable • Minimal invasive code editing• A lot of invasive code editing
  66. 66. Refactoring Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to improve without modifying the code to nonfunctional attributes.” improve modularity”• Code is readable • Code-base is understandable• A lot of invasive code editing • Minimal invasive code editing• Scope: small worlds of a few • Scope: whole code base; what classes at a time; what you see you don‟t see in the IDE in the IDE.
  67. 67. Retrofitting…
  68. 68. Retrofitting…Physical or virtual?
  69. 69. Retrofitting…Physical or virtual?Top-down or bottom-up?
  70. 70. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tangles
  71. 71. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use strategies)
  72. 72. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use strategies)Adjust module boundaries (strengthen abstractions)
  73. 73. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use strategies)Adjust module boundaries (strengthen abstractions)Define layers, visibility
  74. 74. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use strategies)Adjust module boundaries (strengthen abstractions)Define layers, visibilityRepair violations in the implementation levels
  75. 75. Structure101
  76. 76. Restructure101 Structure101
  77. 77. Restructure101 Structure101Visualization
  78. 78. Restructure101 Structure101
  79. 79. Architecture • defined, communicated, enforced Modularity • interfaces, responsibility Structure • encapsulation, coupling Mud • Thank you! Structure101 @chedgey

×