Rediscovering Modularity

Chris Chedgey

Structure101

Gearconf 2012 Dusseldorf

Summary

• We do modularity at implementation levels (classes)

• We don’t do modularity at logical levels (above classes)

• This is not scalable

• We discover it is not scalable when code-base creaks

• The codebase can be salvaged (restructured)

• Step 1: Levelization

Modularity – divide and conquer

• High cohesion

• Low coupling

• Abstraction

• Information hiding

• Interfaces

• Clear responsibility

• …

• S/W-eng 101

• Eng-101

• Human-101 !!

• We ALL know about modularity!

Levels of code quality

Physical

Logical

Classes

Functions

Lines of code

Attention

Imaginationor

Visualization

The modularity wasteland

• Methods ok

• Classes ok

• Handfuls of classes ok

• But almost no logical organization of classes into higher level abstraction

• This is not scalable

Why?

• Logical design is not necessary early on – let it emerge

• In fact it might get in the way

• At some point the sea of classes is too big (50kloc?)

• This point is invariably overshot (no pain => business as usual)

• Package/namespace structures are accidental (like folders)

Symptoms… as code-base grows…

• Cost per feature increases

• Unexpected impacts of change

• Unreliable schedules

• Test cycles increase

• Reuse less

• Value of your code base declines• Asset or liability?

Solutions?

• Do nothing different

• or

• Restructure

• or

• Rebuild

What is restructuring?

Refactoring• “Changing code without

modifying behavior to improve nonfunctional attributes.”

• Code is readable

• A lot of invasive code editing

• Scope: small worlds of a few classes at a time; what you see in the IDE.

Restructuring• “Reorganizing a code-base

without modifying the code to improve modularity”

• Code-base is understandable

• Minimal invasive code editing

• Scope: whole code base; what you don’t see in the IDE

Cost of development

Step 1: Levelization• Remove tangles

• Cyclic dependencies

• Without fat

• Too much complexity in one place (method, class, package, bundle, …)

• Balance

• Eliminate tangles by putting everything in one place - creates fat

• Eliminate fat by simplistically partitioning fat items – creates tangles

Checked automatically

Unlevelized

• Acyclic Dependency Principle (ADP)

• Morning after syndrome

• Release/reuse Principle

• Abstraction, distance from the main sequence

• Clear responsibility?

• Divide and conquer?

• A tangle of items is really a single item

Levelize first

• 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

• Once levelized, other modularity adjustments are “easy”

Visualizing structure - LSM• Info points: #items

• Composition, dependency, flow, whole codebase, filtering, summarizing

• Designed specifically for restructuring

• Demo

• LSM

• Adjusting levelized structure

• Adjusting within tangle

Levelization

• Look at existing logical design (packages, namespaces, assemblies, …)

• Look at the raw material (classes)

• Decide top-down vs. bottom-up

• Break up very large class tangles

• Prioritize non-invasive changes

• Simulate changes before implementing

More restructuring strategies

• Levelize first

• Break v large class tangles early

• Top-down or bottom-up decision

• Do as much as possible by moving classes and packages

• Merge parallel structure

• Address tangles top-down

• Divide disjoint packages early

• Break up v. fat classes and packages early

• Consider mixed granularity

• …

Summary

• We do modularity at implementation levels (classes)

• We don’t do modularity at logical levels (above classes)

• This is not scalable

• We discover it is not scalable when code-base creaks

• The codebase can be salvaged (restructured)

• Step 1: Levelization vote.jax-awards.com

Thank you!

Questions?