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.

1. TOOL-DRIVEN RESTRUCTURING OF
LARGE JAVA CODEBASES
ganesh samarthyam
(ganesh@konfhub.com)

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 benefits)
➤ …

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 fix 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/findbugs/files/findbugs/

7. STARTS WITH AN UNDERSTANDABLE INTENSIONAL STRUCTURE
V 0.7.2

8. GETS SLIGHTLY COMPLICATED
V 0.8.6

9. FIRST TANGLE APPEARS
V 0.8.7

10. AND THE TANGLE SPREADS
V 0.8.8

11. ITS GETTING TOUGHER TO DEAL WITH
V 1.0.0

12. IT IS GETTING WORSER
V 1.3.0

13. ITS A MESS NOW!
V 1.3.5

14. HOW DO WE DEAL WITH THIS SITUATION?

15. ARE YOU IN THIS SITUATION? => DO THIS!

16. ARE YOU IN THIS SITUATION? => DO THIS!

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)

19. DOES MODULARITY MATTER?
Tangles in
JDK

20. “MODULARIZED” SOLUTION (JDK 9)

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)

22. HOW TO EXTRACT A MODULE FROM A TANGLE?

23. HOW TO EXTRACT A MODULE FROM A TANGLE?

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 …

26. APPLYING PRINCIPLES

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

28. IMAGE CREDITS
➤ https://pixabay.com/illustrations/lion-image-editing-graphic-
program-66898/
➤ https://pixabay.com/photos/roofs-houses-historic-center-
italy-919460/

29. www.codeops.tech
www.konfhub.com
www.designsmells.com
ocpjava.wordpress.com
ganesh@codeops.tech
bit.ly/ganeshsg
@GSamarthyam