Rediscovering Modularity - .NET Edition
•
0 j'aime•1,971 vues
Same basic presentation as my JavaOne version, with some graphics replaced by .NET equivalents. I presented this one to Dot Net user groups in Germany and Switzerland.
Recommandé
Contenu connexe
Similaire à Rediscovering Modularity - .NET Edition
Similaire à Rediscovering Modularity - .NET Edition (20)
Dernier
Dernier (20)
Rediscovering Modularity - .NET Edition
- 2. “ The most frequently deployed of software architectures: the BIG BALL OF MUD” Brian Foote
- 3. Mud • Unstructured implementation
- 4. 1. Structure Mud • Composition, coupling • Unstructured implementation
- 5. 2. Modularity 1. Structure Mud • Abstraction, cohesion, interfaces • Composition, coupling • Unstructured implementation
- 6. 3. Architecture 2. Modularity 1. Structure Mud • Defined, communicated, enforced • Abstraction, cohesion, interfaces • Composition, coupling • Unstructured implementation
- 10. Abstraction Interfaces/info hiding Composition Modularity Manage complexity through Encapsulation
- 11. Abstraction Interfaces/info hiding Coupling Composition Modularity Manage complexity through Encapsulation
- 12. Abstraction Interfaces/info hiding Cohesion Coupling Composition Modularity Manage complexity through Encapsulation
- 13. 1. Structure
- 14. 1. Structure • Composition • compositional complexity
- 15. 1. Structure • Composition • compositional complexity • Coupling • levelization
- 16. 1. Structure • Composition • compositional complexity
- 30. Encapsulation Abstraction Interface/hiding Cohesion Coupling Clear responsibility
- 31. Encapsulation Abstraction Interface/hiding Cohesion Coupling Clear responsibility Modularity
- 41. 1. Structure • Coupling • levelization
- 42. Coupling
- 43. Dependencies
- 44. Dependencies
- 47. “Tangles”
- 59. =
- 60. = Not scalable!!
- 61. = Not scalable!!
- 62. Ideally… Start with a loose “architecture”
- 63. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage”
- 64. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed
- 65. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed (~50Kloc – Martin, Foote)
- 66. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed (~50Kloc – Martin, Foote) Structure, Modularize, Define
- 67. Ideally… Start with a loose “architecture” Let suitable architecture emerge, without “baggage” At some point stronger, higher-level abstractions are needed (~50Kloc – Martin, Foote) Structure, Modularize, Define Iterate with development
- 68. 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
- 70. 0.7.2 Mar „04 What actually happens…
- 71. 0.8.6 Oct „04
- 72. 0.8.7 Apr „05
- 73. 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”
- 74. 0.8.8 May „05
- 75. 1.0.0 Jun „06
- 76. 1.3.0 Nov „07
- 77. 1.3.5 Sep „08
- 78. Cost…
- 80. Cost… Miserable developers Cost per feature increases
- 81. Cost… Miserable developers Cost per feature increases Unexpected impacts of change
- 82. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules
- 83. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase
- 84. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less
- 85. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less Value of your code base declines
- 89. 3. Architecture Define, Communicate, Enforce
- 90. Technical Debt
- 91. Technical Debt
- 92. Technical Debt
- 93. Technical Debt
- 101. Abstraction
- 102. Abstraction
- 103. Abstraction
- 104. Abstraction
- 105. Abstraction
- 106. Abstraction
- 107. Abstraction
- 108. Abstraction
- 110. Refactoring • “Changing code without modifying behavior to improve nonfunctional attributes.” Restructuring • “Reorganizing a code-base without modifying the code to improve modularity”
- 111. Refactoring • “Changing code without modifying behavior to improve nonfunctional attributes.” • Code is readable Restructuring • “Reorganizing a code-base without modifying the code to improve modularity” • Code-base is understandable
- 112. Refactoring • “Changing code without modifying behavior to improve nonfunctional attributes.” • Code is readable • A lot of invasive code editing Restructuring • “Reorganizing a code-base without modifying the code to improve modularity” • Code-base is understandable • Minimal invasive code editing
- 113. Refactoring • “Changing code without modifying behavior to improve nonfunctional attributes.” • Code is readable • A lot of invasive code editing • Scope: small worlds of a few classes at a time; what you see in the IDE. Restructuring • “Reorganizing a code-base without modifying the code to improve modularity” • Code-base is understandable • Minimal invasive code editing • Scope: whole code base; what you don‟t see in the IDE
- 114. Modularization…
- 116. Modularization… Decouple implementation levels? Physical or virtual?
- 117. Modularization… Decouple implementation levels? Physical or virtual? Top-down or bottom-up?
- 118. Modularization… Decouple implementation levels? Physical or virtual? Top-down or bottom-up? Create structural model (structure, modularize)
- 119. Modularization… Decouple implementation levels? Physical or virtual? Top-down or bottom-up? Create structural model (structure, modularize) Define/communicate architecture
- 120. Modularization… Decouple implementation levels? Physical or virtual? Top-down or bottom-up? Create structural model (structure, modularize) Define/communicate architecture Repair violations in the implementation levels
- 121. Modularization… Decouple implementation levels? Physical or virtual? Top-down or bottom-up? Create structural model (structure, modularize) Define/communicate architecture Repair violations in the implementation levels Align physical structure with model
- 123. Visualization
- 127. Restructure code-base here …
- 128. Restructure code-base here … …to remove complexity here …
- 129. Restructure code-base here … …to remove complexity here … …and create IDE actions here.
- 133. Define visibility and layering rules here…
- 135. Communicate and enforce at edit and build time…
- 136. Communicate and enforce at edit and build time…
- 137. Thank you! Structure101 @chedgey 3. Architecture 2. Modularity 1. Structure Mud • Defined, communicated, enforced • Abstraction, cohesion, interfaces • Composition, coupling • Unstructured implementation