Retrofitting Architecture - Oredev 2012

1,784 views

Published on

There's a video of me presenting this here: http://oredev.org/2012/sessions/retrofitting-a-software-architecture-to-an-existing-code-base

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,784
On SlideShare
0
From Embeds
0
Number of Embeds
527
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Retrofitting Architecture - Oredev 2012

  1. 1. RetrofittingArchitecture(video)Chris ChedgeyStructure101@chedgeyOredevNovember 9th 2012, Malmo
  2. 2. Architecture • defined, communicated, enforced Modularity • interfaces, responsibility Structure • encapsulation, coupling Mud •
  3. 3. ModularityManage complexity byEncapsulation
  4. 4. Information hiding Modularity Manage complexity by Encapsulation
  5. 5. Information hidingDefined interface Modularity Manage complexity by Encapsulation
  6. 6. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation
  7. 7. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion
  8. 8. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling
  9. 9. Information hidingDefined interface Clear responsibility Modularity Manage complexity by Encapsulation Cohesion Coupling Abstraction
  10. 10. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion
  11. 11. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion Modularity
  12. 12. Complexity Composition
  13. 13. Complexity Composition Cyclomatic Complexity (CC)
  14. 14. (same problem)
  15. 15. Information hiding Clear responsibility Defined interface Coupling AbstractionEncapsulation Cohesion Modularity
  16. 16. Complexity Composition Cyclomatic Complexity (CC)
  17. 17. Complexity CompositionCompositional Complexity (CC)
  18. 18. NamespacesClasses
  19. 19. Information hiding?Clear responsibility Defined interface? Coupling? AbstractionEncapsulation Cohesion Modularity?
  20. 20. Complexity CompositionCompositional Complexity (CC)
  21. 21. Complexity CompositionCompositional Complexity +Hierarchical (CC) => Scalable
  22. 22. Coupling
  23. 23. Dependencies
  24. 24. Dependencies
  25. 25. “Tangles”
  26. 26. =
  27. 27. = Not scalable!!
  28. 28. Ideally…Start with a loose “architecture”
  29. 29. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”
  30. 30. Ideally…Start with a loose “architecture”Let suitable architecture emerge, without “baggage”At some point stronger, higher-level abstractions are needed
  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)
  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 architecture
  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 development
  34. 34. 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
  35. 35. 0.7.2Mar „04
  36. 36. 0.8.6Oct „04
  37. 37. 0.8.7Apr „05
  38. 38. 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”
  39. 39. 0.8.8May „05
  40. 40. 1.0.0Jun „06
  41. 41. 1.3.0Nov „07
  42. 42. 1.3.5Sep „08
  43. 43. Cost…
  44. 44. Cost… Miserable developers
  45. 45. Cost… Miserable developers Cost per feature increases
  46. 46. Cost… Miserable developers Cost per feature increases Unexpected impacts of change
  47. 47. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules
  48. 48. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase
  49. 49. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less
  50. 50. Cost… Miserable developers Cost per feature increases Unexpected impacts of change Unreliable schedules Test cycles increase Reuse less Value of your code base declines
  51. 51. Technical Debt
  52. 52. Technical Debt
  53. 53. Technical Debt
  54. 54. Technical Debt
  55. 55. Abstraction
  56. 56. Abstraction
  57. 57. Abstraction
  58. 58. Abstraction
  59. 59. Abstraction
  60. 60. Abstraction
  61. 61. Abstraction
  62. 62. Abstraction
  63. 63. Refactoring Restructuring
  64. 64. Refactoring Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to without modifying the code to improve nonfunctional improve modularity” attributes.”
  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
  66. 66. 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
  67. 67. 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.
  68. 68. Retrofitting…
  69. 69. Retrofitting…Physical or virtual?
  70. 70. Retrofitting…Physical or virtual?Top-down or bottom-up?
  71. 71. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tangles
  72. 72. Retrofitting…Physical or virtual?Top-down or bottom-up?Bust big class tanglesCreate a structured model (levelized+CC) (use strategies)
  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)
  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, visibility
  75. 75. 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
  76. 76. Structure101
  77. 77. Restructure101 Structure101
  78. 78. Restructure101 Structure101
  79. 79. Restructure101 Structure101
  80. 80. Architecture • defined, communicated, enforced Modularity • interfaces, responsibility Structure • encapsulation, coupling Mud • Thank you! Chris Chedgey Structure101 @chedgey (video)

×