It is challenging to deal with the complexity of the large (often legacy) software codebases where the fear of breaking the working code and difficulty in understanding existing structure are major challenges. Modularizing your codebase with minimal code changes and risk with maximal benefit can enhance agility and improve the productivity and morale of the teams.
In this session, I take you through case-studies and examples on how to modularize large open source codebases by removing tangles and fat. I cover both low-level physical refactoring through invasive code changes as well as modularization at architectural level without making code changes (and discuss the differences).
By attending this session, participants will know strategies, specific techniques , and tools for modularizing their code by performing as much minimal (sometimes no) code changes as possible with least risk of breaking the working software.
Target audience: Java Developers, leads and architects.
2. LARGE (LEGACY) CODE
†Positives:
†Working code
†Tried and tested
†Stable & known
†âŠ
†Negatives:
†âTouch here breaks thereâ (lack of visibility &
deteriorating structure)
†No ONE knows how it works (but we do know
it works!)
†Limited resources (unclear investment beneïŹts)
†âŠ
3. ââThe problem with quick and dirtyâŠ
is that dirty remains long after quick
has been forgotten!â
- Steve C McConnell
4. CORE ISSUE: DIFFICULT TO UNDERSTAND & LACKS STRUCTURE
†Lack of shared understanding of the whole system
†Original developers have long left the team
†New developers take a long time to become productive
†Structure has deteriorated over time (existing structure works
against development)
†Accidental changes to the structure (on need basis) than
intentional changes that preserves structure
†Changing code is âperceived riskyâ - hard to predict impact
†As developers we donât know how to ïŹx the code or add
features; when we know, canât be sure if it wonât break
anything (lack of automated unit tests adds to the problem)
5. Source: Consortium of IT Software Quality (CISQ), Bill Curtis, Architecturally Complex Defects, 2012
6. WHICH ONE WOULD YOU LIKE TO WORK ON?
V 0.7.2
V 1.3.5
https://sourceforge.net/projects/ïŹndbugs/ïŹles/ïŹndbugs/
7. STARTS WITH AN UNDERSTANDABLE INTENSIONAL STRUCTURE
V 0.7.2
17. UNDERSTANDING PHYSICAL/CLASS TANGLES
Step 1: Separate the interface & implementation
Step 2: Depend on the interfaces (and not on the implementations)
(Reflection: Needs code-level changes)
18. UNDERSTANDING PACKAGE-LEVEL TANGLES
Step 1: Create a separate package for the interface(s)
Step 2: Separate the interface & implementation
(Reflection: Needs package-moves - no code level changes)
21. MODULARITY IS THE KEY: REMOVING TANGLES AND FAT
†Tangles - entities are directly or indirectly depending on each
other (classes, packages, etc)
†Fat - excessive complexity of an entity (methods, classes,
packages etc)
24. EXTRACTING âCLASSREALMâ CAUSES A CYCLE
Step: Separate the interfaces in âmaven-classrealmâ from the
implementation (concrete classes) into to a separate module
(âmaven-classrealm-apiâ)
(Reflection: NO CODE CHANGE(S) NEEDED!!)
25. TOOLS FOR REFACTORING & RESTRUCTURING
†CodeScene
†Designite
†JArchitect / NDepend / CppDepend
†Lattix
†ReSharper
†Sotograph / SotoArc
†and more âŠ
27. CREDITS
†For the FindBugs example: Structure101 team
†For applying principles image: our book âRefactoring for
Software Design Smellsâ
†Module system in JDK 9 - blogs.oracle.com
†For the âmaven class-realmâ module extraction case study:
Mike Swainston-Rainford
†Source for the quotation: Consortium of IT Software Quality
(CISQ), Bill Curtis, Architecturally Complex Defects, 2012