Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
•
0 j'aime•874 vues
Recommandé
Recommandé
Contenu connexe
Similaire à Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
Similaire à Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012 (20)
Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012
- 1. Rediscovering Modularity Chris Chedgey Structure101 @chedgey Stuttgart, Munich, Nuremberg November 20th – 22nd 2012
- 2. Modularity Manage complexity by Encapsulation
- 3. Information hiding Modularity Manage complexity by Encapsulation
- 4. Information hiding Defined interface Modularity Manage complexity by Encapsulation
- 5. Information hiding Defined interface Clear responsibility Modularity Manage complexity by Encapsulation
- 6. Information hiding Defined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion
- 7. Information hiding Defined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling
- 8. Information hiding Defined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling Abstraction
- 11. Information hiding Clear responsibility Defined interface Coupling Abstraction Encapsulation Cohesion
- 12. Information hiding Clear responsibility Defined interface Coupling Abstraction Encapsulation Cohesion Modularity
- 13. Complexity Composition
- 14. Complexity Composition Cyclomatic Complexity (CC)
- 19. (same problem)
- 21. Information hiding Clear responsibility Defined interface Coupling Abstraction Encapsulation Cohesion Modularity
- 23. Complexity Composition Cyclomatic Complexity (CC)
- 24. Complexity Composition Compositional Complexity (CC)
- 27. Packages Classes
- 28. Information hiding?Clear responsibility Defined interface? Coupling? Abstraction Encapsulation Cohesion Modularity?
- 29. Complexity Composition Compositional Complexity (CC)
- 30. Complexity Composition Compositional Complexity +Hierarchical (CC) => Scalable
- 31. Coupling
- 32. Dependencies
- 33. Dependencies
- 36. “Tangles”
- 47. =
- 48. = Not scalable!!
- 49. Ideally… Start with a loose “architecture”
- 50. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage”
- 51. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed
- 52. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed (~50Kloc – Martin, Foote)
- 53. 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
- 54. 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 Iterate with development
- 55. 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 Iterate with development Strengthen with growth
- 56. 0.7.2 Mar „04
- 57. 0.8.6 Oct „04
- 58. 0.8.7 Apr „05
- 59. 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”
- 60. 0.8.8 May „05
- 61. 1.0.0 Jun „06
- 62. 1.3.0 Nov „07
- 63. 1.3.5 Sep „08
- 64. Cost…
- 65. Cost… Miserable developers
- 66. Cost… Miserable developers Cost per feature increases
- 67. Cost… Miserable developers Cost per feature increases Unexpected impacts of change
- 68. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules
- 69. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase
- 70. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less
- 71. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less Value of your code base declines
- 72. Technical Debt
- 73. Technical Debt
- 74. Technical Debt
- 75. Technical Debt
- 83. Abstraction
- 84. Abstraction
- 85. Abstraction
- 86. Abstraction
- 87. Abstraction
- 88. Abstraction
- 89. Abstraction
- 90. Abstraction
- 91. Refactoring Restructuring
- 92. Refactoring Restructuring • “Changing code without • “Reorganizing a code-base modifying behavior to without modifying the code to improve nonfunctional improve modularity” attributes.”
- 93. 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
- 94. 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
- 95. 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.
- 96. Retrofitting…
- 98. Retrofitting… Physical or virtual? Top-down or bottom-up?
- 99. Retrofitting… Physical or virtual? Top-down or bottom-up? Bust big class tangles
- 100. Retrofitting… Physical or virtual? Top-down or bottom-up? Bust big class tangles Create a structured model (levelized+CC) (use strategies)
- 101. Retrofitting… Physical or virtual? Top-down or bottom-up? Bust big class tangles Create a structured model (levelized+CC) (use strategies) Adjust module boundaries (strengthen abstractions)
- 102. Retrofitting… Physical or virtual? Top-down or bottom-up? Bust big class tangles Create a structured model (levelized+CC) (use strategies) Adjust module boundaries (strengthen abstractions) Define layers, visibility
- 103. Retrofitting… Physical or virtual? Top-down or bottom-up? Bust big class tangles Create a structured model (levelized+CC) (use strategies) Adjust module boundaries (strengthen abstractions) Define layers, visibility Repair violations in the implementation levels
- 105. Structure101
- 107. Restructure101 Structure101 Visualization
- 109. Architecture • defined, communicated, enforced Modularity • interfaces, responsibility Structure • encapsulation, coupling Mud • Thank you! Structure101 @chedgey