The document discusses restructuring code to improve modularity. It defines restructuring as reorganizing a codebase without modifying code to improve understandability. The author advocates using visualization tools like Levelized Structure Maps to understand a codebase's structure at a global level in order to divide it into coherent modules. Various restructuring strategies are presented, including merging parallel structures, busting large class tangles, and moving classes and packages to improve dependencies before further refactoring. The goal is to tackle complexity before modularity to make the codebase easier to comprehend and maintain.

1. Restructuring
Improving the modularity of an existing code-base
Chris Chedgey
www.structure101.com

2. Structure101.com - People
• Chris Chedgey, Dunmore East, Ireland
• Paul Hickey, Toulouse, France
• Paul O’Reilly, Enniscorthy, Ireland
• Raghvendra Sahu, Delhi, India
• + 3 contractors
• No VC’s, no suits

3. Structure101.com - Products
• Restructure101
• Fix architecture
• Structure101
• Define it
• Structure101 Build
• Enforce it
• Java, .NET, C/C++, Actionscript, php, …
• 1,000’s users in 100’s companies

4. Topics
• What is “Restructuring”?
• Motivation
• Understanding structure
• Restructuring strategies
• Examples
• Keeping it structured

5. What is restructuring?
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.

6. What is structure?
• Composition
• Dependencies that roll up through composition
• Nested “levels”
• Quality factors
• Complexity
• Modularity

7. Why is it important?
• Determines cost of development
• Predictable impact
• Testability
• Reusability
• Value of your code base
• Asset or liability?

8. Structural quality: complexity
• Fat • Eliminate tangles by putting
everything in one place -
• Too much complexity in one creates fat
place (method, class,
package, bundle, …) • Eliminate fat by simplistically
• Tangles partitioning fat items – creates
tangles
• Cyclic dependencies
• Cumulative Component
Dependency (CCD, Lakos) Checked
goes through the roof automatically
• Acyclic Dependency Principle
(ADP, Bob Martin) – morning
after syndrome

9. Structural quality: modularity
• High cohesion • S/W-eng 101
• Low coupling • We ALL know about
modularity!
• Information hiding
• Interfaces
Checked
• Clear responsibility
by human architect
• …

10. Visualizing structure – core features
• Composition
• Dependency
• Flow of dependencies
• Whole codebase
• Filtering
• Summarizing
• Comprehension

11. Visualizing structure: approaches
• Lists and treeview
• Directed graph
• Dependency Structure Matrix (DSM)
• Levelized Structure Map (LSM)

12. Visualizing structure - list & treeview
• Good to discover specific
information
• No dependency flow,
manipulation

13. Visualizing structure: directed graphs
• Info points: #items + #deps
• Levelizable – good flow
• #deps becomes a problem
• Indicate fat, not fix
• Infinite nesting not feasible
• Local comprehension, not for
global/manipulation

14. Visualizing structure: DSM
• Info points: #items2
• “Scalable” - can be rendered for
v large graphs
• Infinite nesting possible
• Whole code-base
• Manipulation possible
• Grow v large
• Hard to read, bad for the neck

15. Visualizing structure - LSM
• Info points: #items
• Composition, dependency,
flow, whole codebase,
filtering, summarizing
• Goldilocks – designed
specifically for restructuring

16. The modularity wasteland
• Methods ok
• Classes ok
• Handfuls of classes ok
• Overlapping “small worlds”
• Plenty of guidelines
• Smells and refactoring
• But almost no logical organization
of classes into higher level
modules
• This is not scalable

17. “But we use Java packages!”
• ` !!
• Hierarchical ok
• Support visibility ok
• BUT: used like a filesystem, not as an
embodiment of module hierarchy
• Composition only
• No consideration of dependencies
• Little consideration of visibility
• Too easy to change (without rules/tools)
• Becomes a big tangled mess

18. Modularity stops at class level?
• Finite aggregation is not
scalable
• Oceans of classes
• Still need to divide and
conquer
• Even more – affects the
whole team
• Is it inevitable?

19. Inevitable?
• No!
• Spring:

20. Restructuring strategies
• Merge parallel structure • Do as much as possible by
moving classes and packages
• Top-down or bottom-up
decision • Divide disjoint packages early
• Tackle complexity before • Break up v. fat classes and
modularity packages early
• Break v large class tangles • Disentangle
early
• Consider mixed granularity
• Address tangles top-down
• …

21. Merge parallel structures
• Common to separate interfaces/api
from implementation
• Perhaps attempt to increase
awareness of visibility
• Obscures module structure esp if
higher in hierarchy
• Better to consider module sub-items
as siblings with visibility
• Keep both if there is a strong
need/desire for physical code to be
separate
• Use of transformations

22. Merge parallel structures

23. Bust v large class tangles early
• Often there is 1 or a few v.large • Can the class tangle be contained
tangles spanning many packages within a single package?
• Making those packages acyclic • At least for now?
means busting the class tangle
• Not if classes span to much of the
• Does it span multiple higher-level layering
layers?
• Not if it represents a significant
• Break the feedback dependencies portion of your code base
between the layers
• Can you break the tangle into several
acyclic subsets of tangles?
• Each subset can be contained within
a single package
• Each subset can be contained within a
narrow range of ideal leveling

24. Do as much as you can by moving
classes/packages first
• Low effort refactoring
• Less invasive surgery so less risk of impacting behavior
• Biggest bang for the buck, unless there are v.large class tangles
• Option to manage architecture separate from physical code
• Map classes to physical components
• Can’t be done if model requires invasive class editing

25. Top-down or bottom-up?
• Top-down • A bit of both
• Preserves as much of the package • Preserve top-level breakout
hierarchy as possible
• May reflect team structure
• Team can still find classes
• Often reflects initial architecture
• Feasible if the target structure is
• Sub-modules were not explicitly
close to the current designed
• Bottom-up • Preserve in regions where there is
relatively small amount of
• Current packaging is of little use restructuring
• Target structure is far from current
• Often easiest to implement

26. Make items only using or used by a tangle

27. Move only used/using child items

28. Split disjoint packages

29. Split fat packages and classes

30. Move feeback from/top

31. Move feedback to/bottom

32. Move tangles together

33. Tackle complexity before (other)
modularity
• A structure without tangles is much easier to manipulate
• A milestone in its own right
• A code-base that is much easier to understand
• Many simply focus on keeping (over-)complexity out
• Good basis for further modularization (coupling, cohesion,
interfaces, …)

34. Summary
• The modularity wasteland is normal
• It costs
• It can be salvaged
• It is not easy, but the returns can be huge
• Questions?
• Thank you!