Rediscovering Modularity

Rediscovering ModularityChris ChedgeyStructure101Gearconf 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 • S/W-eng 101• Low coupling • Eng-101• Abstraction • Human-101 !!• Information hiding • We ALL know about modularity!• Interfaces• Clear responsibility• …

Levels of code quality Physical Imagination or Logical Visualization Classes Functions Attention Lines of code

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 Restructuring• “Changing code without • “Reorganizing a code-base modifying behavior to improve without modifying the code to nonfunctional attributes.” improve modularity” Cost of• Code is readable development• 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.

Step 1: Levelization• Remove tangles • Balance • Cyclic dependencies • Eliminate tangles by putting everything in one place - creates• Without fat fat • Too much complexity in one place (method, class, package, • Eliminate fat by simplistically bundle, …) 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 • Divide disjoint packages early• Break v large class tangles early • Break up v. fat classes and packages early• Top-down or bottom-up decision • Consider mixed granularity• Do as much as possible by moving classes and packages • …• Merge parallel structure• Address tangles top-down

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?

Rediscovering Modularity

by Chris Chedgey on Jun 29, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 9

Statistics