Rediscovering Modularity - .NET Edition
â˘
0 gefällt mirâ˘1,971 views
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.
Empfohlen
Weitere ähnliche Inhalte
Ăhnlich wie Rediscovering Modularity - .NET Edition
Ăhnlich wie Rediscovering Modularity - .NET Edition (20)
KĂźrzlich hochgeladen
KĂźrzlich hochgeladen (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