RestructuringImproving the modularity of an existing code-base                  Chris Chedgey                   Structure101
Structure101 - People•   Chris Chedgey, Dunmore East, Ireland•   Paul Hickey, Toulouse, France•   Paul O’Reilly, Enniscort...
Structure101 - Products•   Restructure101      •   Fix architecture•   Structure101      •   Define it•   Structure101 Bui...
Topics•   What is “Restructuring”?•   Motivation•   Understanding structure•   Restructuring strategies•   Examples
What is restructuring?Refactoring                           Restructuring•   “Changing code without            •   “Reorga...
What is structure?•   Composition•   Dependencies that roll up through composition•   Nested “levels”•   Quality factors  ...
Why is structure important?•   Determines cost of development      •   Understandability•   Predictable impact of changes•...
Structural quality 1: complexity•   Fat                                  •   Eliminate tangles by putting                 ...
Structural quality 2: modularity•   High cohesion          •   S/W-eng 101•   Low coupling           •   We ALL know about...
Working with structure – core features•   Composition + Dependency•   Flow of dependency•   Whole codebase•   Filtering•  ...
Working with structure•    Lists and treeview•    Directed graph•    Dependency Structure Matrix (DSM)•    Levelized Struc...
Working with structure: list & treeview•   Good to discover specific    information•   No dependency flow,    manipulation
Visualizing structure: directed graphs•   Info points: #items + #deps•   Levelizable – good flow•   #deps becomes a proble...
Visualizing structure: DSM•   Info points: #items2•   “Scalable” - can be rendered for    v large graphs•   Infinite nesti...
Visualizing structure - LSM•   Info points: #items•   Composition, dependency,    flow, whole codebase,    filtering, summ...
The modularity wasteland•   Methods ok•   Classes ok•   Handfuls of classes ok       •   Overlapping “small worlds”       ...
“But we use Java packages!”•   Bollox!!•   Hierarchical ok•   Support visibility ok•   BUT: used like a filesystem, not as...
Modularity stops at class level?•   Finite aggregation is not    scalable•   Oceans of classes•   Still need to divide and...
Inevitable?•   No!•   Spring:
Restructuring strategies•   Merge parallel structure      •   Do as much as possible by                                   ...
Merge parallel structures•   Common to separate interfaces/api    from implementation•   Perhaps attempt to increase    aw...
Merge parallel structures
Bust v large class tangles early•   Often there is 1 or a few v.large        •   Can the class tangle be contained    tang...
Do as much as you can by movingclasses/packages first•   Low effort refactoring•   Less invasive surgery so less risk of i...
Top-down or bottom-up?•   Top-down                                     •   A bit of both      •   Preserves as much of the...
Make items only using or used by a tangle
Move only used/using child items
Split disjoint packages
Split fat packages and classes
Move feeback from/top
Move feedback to/bottom
Move tangles together
Tackle complexity before (other)modularity•   A structure without tangles is much easier to manipulate•   A milestone in i...
Summary•   The modularity wasteland is normal•   It costs•   It can be salvaged•   It is not easy, but the returns can be ...
Upcoming SlideShare
Loading in …5
×

Restructuring- improving the modularity of an existing code-base

2,256 views
2,193 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,256
On SlideShare
0
From Embeds
0
Number of Embeds
243
Actions
Shares
0
Downloads
16
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Guten abendIch bin ein berlinerDarmstadterGood few years agoBit for freedomLast bit of useless info We dev tools – talk not about these – talk after formal pres
  • 6 components to the company, 4 human, 2 beautifulWe don’t own suitsLove what we doRelentless innovation to solve a big problem
  • What – relate to refactoringMotivation – modularity/scalabilityUnderstanding – quantifying over complexityRestructuring strategies – emerging from experience, dozens of client engagements and use casesShow parts of products to illustrate principles, not a tutorial on the products
  • Don’t care whether you use inheritance or aggregationThink of a mass of lines of code, currently organized in one way into methods, classes, packages – we want to reorganize the same lines of code into a different hierarchy of methods, classes, packages.
  • Can you test a tangle of hundreds of classes?Can’t reuse subsets if everything uses everythingWhen a code-base becomes a liability, sw-engineering has failed
  • Structural complexity can be assigned thresholds and checked objectively/automatically
  • We learn about modularity in SW-eng101Builds on complexity principles
  • Another representation of a graphManipulation involves dragging rows and columns around
  • Restructuring- improving the modularity of an existing code-base

    1. 1. RestructuringImproving the modularity of an existing code-base Chris Chedgey Structure101
    2. 2. Structure101 - 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. 3. Structure101 - 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. 4. Topics• What is “Restructuring”?• Motivation• Understanding structure• Restructuring strategies• Examples
    5. 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. 6. What is structure?• Composition• Dependencies that roll up through composition• Nested “levels”• Quality factors • 1. Complexity Complexity Modularity • 2. Modularity
    7. 7. Why is structure important?• Determines cost of development • Understandability• Predictable impact of changes• Testability• Reusability• Value of your code base • Asset or liability?
    8. 8. Structural quality 1: complexity• Fat • Eliminate tangles by putting everything in one place - • Too much stuff in one place creates fat (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. 9. Structural quality 2: modularity• High cohesion • S/W-eng 101• Low coupling • We ALL know about modularity!• Information hiding• Interfaces Checked• Clear responsibility by human architect• …
    10. 10. Working with structure – core features• Composition + Dependency• Flow of dependency• Whole codebase• Filtering• Summarizing• Comprehension
    11. 11. Working with structure• Lists and treeview• Directed graph• Dependency Structure Matrix (DSM)• Levelized Structure Map (LSM)
    12. 12. Working with structure: list & treeview• Good to discover specific information• No dependency flow, manipulation
    13. 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. 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. 15. Visualizing structure - LSM• Info points: #items• Composition, dependency, flow, whole codebase, filtering, summarizing• Goldilocks – designed specifically for restructuring
    16. 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. 17. “But we use Java packages!”• Bollox!!• 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. 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. 19. Inevitable?• No!• Spring:
    20. 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. 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. 22. Merge parallel structures
    23. 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. 24. Do as much as you can by movingclasses/packages first• Low effort refactoring• Less invasive surgery so less risk of impacting behavior• Exception – static classes• 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. 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. 26. Make items only using or used by a tangle
    27. 27. Move only used/using child items
    28. 28. Split disjoint packages
    29. 29. Split fat packages and classes
    30. 30. Move feeback from/top
    31. 31. Move feedback to/bottom
    32. 32. Move tangles together
    33. 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. 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!

    ×