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.
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
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”
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
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
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