Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Tool Driven Restructuring of Large Java Codebases

187 visualizaciones

Publicado el

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.

Publicado en: Software
  • Sé el primero en comentar

Tool Driven Restructuring of Large Java Codebases

  1. 1. TOOL-DRIVEN RESTRUCTURING OF LARGE JAVA CODEBASES ganesh samarthyam (ganesh@konfhub.com)
  2. 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. 3. ““The problem with quick and dirty… is that dirty remains long after quick has been forgotten!” - Steve C McConnell
  4. 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. 5. Source: Consortium of IT Software Quality (CISQ), Bill Curtis, Architecturally Complex Defects, 2012
  6. 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. 7. STARTS WITH AN UNDERSTANDABLE INTENSIONAL STRUCTURE V 0.7.2
  8. 8. GETS SLIGHTLY COMPLICATED V 0.8.6
  9. 9. FIRST TANGLE APPEARS V 0.8.7
  10. 10. AND THE TANGLE SPREADS V 0.8.8
  11. 11. ITS GETTING TOUGHER TO DEAL WITH V 1.0.0
  12. 12. IT IS GETTING WORSER V 1.3.0
  13. 13. ITS A MESS NOW! V 1.3.5
  14. 14. HOW DO WE DEAL WITH THIS SITUATION?
  15. 15. ARE YOU IN THIS SITUATION? => DO THIS!
  16. 16. ARE YOU IN THIS SITUATION? => DO THIS!
  17. 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. 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. 19. DOES MODULARITY MATTER? Tangles in JDK
  20. 20. “MODULARIZED” SOLUTION (JDK 9)
  21. 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. 22. HOW TO EXTRACT A MODULE FROM A TANGLE?
  23. 23. HOW TO EXTRACT A MODULE FROM A TANGLE?
  24. 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. 25. TOOLS FOR REFACTORING & RESTRUCTURING ➤ CodeScene ➤ Designite ➤ JArchitect / NDepend / CppDepend ➤ Lattix ➤ ReSharper ➤ Sotograph / SotoArc ➤ and more …
  26. 26. APPLYING PRINCIPLES
  27. 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. 28. IMAGE CREDITS ➤ https://pixabay.com/illustrations/lion-image-editing-graphic- program-66898/ ➤ https://pixabay.com/photos/roofs-houses-historic-center- italy-919460/
  29. 29. www.codeops.tech www.konfhub.com www.designsmells.com ocpjava.wordpress.com ganesh@codeops.tech bit.ly/ganeshsg @GSamarthyam

×