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”

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…

97. Retrofitting… Physical or virtual?

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

106. Restructure101 Structure101

107. Restructure101 Structure101 Visualization

108. Restructure101 Structure101

109. Architecture • defined, communicated, enforced Modularity • interfaces, responsibility Structure • encapsulation, coupling Mud • Thank you! Structure101 @chedgey

Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012

Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012

Recommended

More Related Content

Similar to Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012

Similar to Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012(20)

Rediscovering Modularity - Java User Groups, Stuttgart, Munich, Nuremberg, November 2012