Bridging the Divide between Architecture and Code (Germany JUGs version)
Report
Share
•1 like•431 views
Bridging the Divide between Architecture and Code (Germany JUGs version)
•1 like•431 views
Report
Share
Download to read offline
(Version from German JUG talks April 2018) Abstract Static diagrams on wikis and white-boards might capture the vision of architects, but they don’t much help programmers to understand how the code they’re working on right now fits into the architecture. Nor are the programmers warned when they violate the diagrams as they forge changes, line-by-line. This is a huge problem – it is ultimately individual lines of code that make or break an architecture; and we know that a clean architecture will help teams develop a more flexible product, with less complexity, less wasted effort, etc. Worse, without practical architectural guidance, programmers wrestle with invisible structures that emerge from thousands of inter-dependent lines of code. And being invisible, these structures become ever more complex, coupled, and tangled. In fact, uncontrolled structure actively fights against productive development. This talk shows how to rein in emergent code-base structures and gradually transform them into a cogent, defined architecture. You will see how… - Visualizing the emergent structure makes a code-base easier to understand. - Restructuring to remove tangles and reduce coupling makes the visualized code-base easier to work on. - Specifying layering and dependency rules converts good structure into a controlled architecture that guides the team as the code-base evolves and grows. A key ingredient is a live visualization, inside the IDE, of the detailed code the programmer is working on, in the context of the overall architecture. In short, you will learn how bridging the architect/programmer divide can convert code-base structure from liability into an asset that actively works for development productivity.
Recommended
More Related Content
Similar to Bridging the Divide between Architecture and Code (Germany JUGs version)
Similar to Bridging the Divide between Architecture and Code (Germany JUGs version)(20)
More from Chris Chedgey
More from Chris Chedgey(7)
Recently uploaded
Recently uploaded(20)
Bridging the Divide between Architecture and Code (Germany JUGs version)
- 1. Bridging the Divide between Architecture and Code Chris Chedgey Structure101
- 4. ?
- 7. ✗
- 8. ✗
- 9. ✗ ✗
- 10. The Divide is a problem because…
- 11. The Divide is a problem because… • Invisible, emergent, accidental structure fights against developers
- 12. The Divide is a problem because… • Invisible, emergent, accidental structure fights against developers • Invisible, disconnected architecture could guide developers … but doesn’t
- 13. The Divide is a problem because… • Invisible, emergent, accidental structure fights against developers • Invisible, disconnected architecture could guide developers … but doesn’t
- 14. Invisible structure fights developers because… • Invisible structure becomes tangled
- 15. V 0.7.2
- 16. V 0.8.6
- 17. V 0.8.7
- 18. V 0.8.8
- 19. V 1.0.0
- 20. V 1.3.0
- 21. V 1.3.5
- 22. • Invisible structure becomes tangled Invisible structure fights developers because…
- 23. • Invisible structure becomes tangled • Tangles increase complexity Invisible structure fights developers because…
- 24. Tangles increase complexity CCD = (1*1) + (11*2) + (7*3) + … ~ 164 CCD = 362 = 1,296 !!! Cumulative Component Dependency (John Lakos)
- 25. • Invisible structure becomes tangled • Tangles increase complexity Invisible structure fights developers because…
- 26. • Invisible structure becomes tangled • Tangles increase complexity • Complexity is hard to understand Invisible structure fights developers because…
- 27. Complexity is hard to understand
- 28. • Invisible structure becomes tangled • Tangles increase complexity • Complexity is hard to understand Invisible structure fights developers because…
- 29. • Invisible structure becomes tangled • Tangles increase complexity • Complexity is hard to understand • Tangles make a monolith Invisible structure fights developers because…
- 30. Tangles make a monolith
- 31. Tangles make a monolith
- 32. Tangles make a monolith
- 33. Tangles make a monolith
- 34. Tangles make a monolith ✗
- 35. • Invisible structure becomes tangled • Tangles increase complexity • Complexity is hard to understand • Tangles make a monolith Invisible structure fights developers because…
- 36. The Divide is a problem because… • Invisible, emergent, accidental structure fights against developers • Invisible, disconnected architecture could guide developers … but doesn’t
- 37. The Divide is a problem because… • Invisible, emergent, accidental structure fights against developers • Invisible, disconnected architecture could guide developers … but doesn’t
- 38. Architecture could guide developers
- 39. Architecture could guide developers • Define/enforce layering
- 40. Architecture could guide developers • Define/enforce layering
- 41. Architecture could guide developers • Define/enforce layering
- 42. Architecture could guide developers • Define/enforce layering
- 43. Architecture could guide developers • Define/enforce layering • Group related modules/packages
- 44. Architecture could guide developers • Define/enforce layering • Group related modules/packages
- 45. Architecture could guide developers • Define/enforce layering • Group related modules/packages
- 46. Architecture could guide developers • Define/enforce layering • Group related modules/packages
- 47. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation
- 48. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation
- 49. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation
- 50. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation
- 51. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation • Allow for future module replacement
- 52. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation • Allow for future module replacement • Guide new developers
- 53. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation • Allow for future module replacement • Guide new developers • Phased/parallel development
- 54. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation • Allow for future module replacement • Guide new developers • Phased/parallel development • Modularity!
- 55. Architecture could guide developers • Define/enforce layering • Group related modules/packages • Define/enforce interface-implementation • Prevent dependency proliferation • Allow for future module replacement • Guide new developers • Phased/parallel development • Modularity! • …
- 63. Bridging the divide 1. Start visualizing the structure you have now
- 64. Bridging the divide 1. Start visualizing the structure you have now 2. Lock-in any useful architecture you have now – overlay the visualization
- 65. Bridging the divide 1. Start visualizing the structure you have now 2. Lock-in any useful architecture you have now – overlay the visualization 3. Improve/extend the architecture – development gets easier and easier
- 66. • You’re going to need a tool… • That parses code • Hierarchical dependency model • Architectural overlays
- 67. • You’re going to need a tool… • That parses code • Hierarchical dependency model • Architectural overlays • SonarGraph Hierarchical dependency graph
- 68. DSM - Dependency Structure Matrix • You’re going to need a tool… • That parses code • Hierarchical dependency model • Architectural overlays • SonarGraph • Lattix • IntelliJ Idea Ultimate Hierarchical dependency graph
- 69. DSM - Dependency Structure Matrix LSM – Levelized Structure Map • You’re going to need a tool… • That parses code • Hierarchical dependency model • Architectural overlays • SonarGraph • Lattix • IntelliJ Idea Ultimate • Structure101 Hierarchical dependency graph
- 70. Step 1: Visualize what you have
- 71. Step 1: Visualize what you have • Immediate productivity boost – A map of the codebase
- 72. Step 1: Visualize what you have • Immediate productivity boost – A map of the codebase • See the details in the context of the de facto architecture, e.g. – Eclipse projects – IntelliJ modules – Maven POMs – Java 9 modules – …
- 73. Step 1: Visualize what you have • Immediate productivity boost – A map of the codebase • See the details in the context of the de facto architecture, e.g. – Eclipse projects – IntelliJ modules – Maven POMs – Java 9 modules – … • Raise structural awareness – Start simplifying the codebase - reduce coupling and complexity
- 74. Step 1: Visualization Demo
- 75. Step 2: Lock in and shore up de facto architecture
- 76. Step 2: Lock in and shore up de facto architecture • Organize modules into groups
- 77. Step 2: Lock in and shore up de facto architecture • Organize modules into groups • Specify module dependency constraints
- 78. Step 2: Lock in and shore up de facto architecture • Organize modules into groups • Specify module dependency constraints • Overlay onto the visualization – Understand the details in the context of the spec’d architecture – Warned immediately if edits violate spec
- 79. Step 2: Structure Spec Demo
- 80. Step 3: Incrementally improve the architecture/structure
- 81. Step 3: Incrementally improve the architecture/structure • Deal with the monoliths – Increase %specified
- 82. Step 3: Incrementally improve the architecture/structure • Deal with the monoliths – Increase %specified • Lift lower packages into modules
- 83. Step 3: Incrementally improve the architecture/structure • Deal with the monoliths – Increase %specified • Lift lower packages into modules • Disentangle packages… – Small/easy: In the code – Broader: Simulate first – Move classes, then refactor for dependencies
- 84. Step 3: Incrementally improve the architecture/structure • Deal with the monoliths – Increase %specified • Lift lower packages into modules • Disentangle packages… – Small/easy: In the code – Broader: Simulate first – Move classes, then refactor for dependencies • … and/or Extract modules – Simulate first – Add new module to spec – Refactor for dependencies, then move classes
- 85. Step 3: Structure101 Studio Demo
- 87. Bridging the gap… Summary 1. Start visualizing the structure you have now
- 88. Bridging the gap… Summary 1. Start visualizing the structure you have now 2. Lock-in and shore-up any useful architecture you have now – overlay the visualization
- 89. Bridging the gap… Summary 1. Start visualizing the structure you have now 2. Lock-in and shore-up any useful architecture you have now – overlay the visualization 3. Improve/extend the architecture – development gets easier and easier
- 90. Questions? @chedgey chris@structure101.com structure101.com Early access to Workspace: 2018.structure101.com
Editor's Notes
- You cannot do structure in the IDE alone – structure emerges from the code
- You cannot do structure in the IDE alone – structure emerges from the code
- You cannot do structure in the IDE alone – structure emerges from the code
- You cannot do structure in the IDE alone – structure emerges from the code