Making sense of large Java and Kotlin classes

Presented at IntelliJ IDEA by JetBrains YouTube Webinar on Nov 23, 2022.
Video link https://www.youtube.com/watch?v=MtXEszV787g

Profitable software could last for several years, if not decades. They have the fingerprints of tens or hundreds of developers that have helped the software deliver value to its customers. Even though many developers dream of greenfield projects, in reality most of us work with projects where a fresh start is a pipedream. If you have inherited a codebase built by other developers or if you are moving to a team whose codebase is unfamiliar territory, you inevitably end up spending time trying to understand the codebase. Common approaches include reading source code, navigating the call graph, reading documentation, looking at UML or sequence diagrams, and even setting breakpoints to understand the source code. These techniques usually work, but what if there's a better way to understand small and large classes on codebases that you don't have prior experience with?

In this session, we will start with the first principles of approaching and understanding unknown classes. You will also learn to ask the right questions about code, spot potential problems and code smells, and even plan your refactoring (for when you are trying to extract clusters from a large class or split them into smaller ones).

Transcript

1. Making sense of large Java
   and Kotlin classes
   Ragunath Jawahar
   ragunath@redgreen.io
   

   View Slide

2. Agenda 1. Fundamentals
   2. Tooling demo 🥳
   3. Refactoring demo 🥳
   

   View Slide

3. 80/20 rule 80% of the value your
   software delivers to your
   customers comes from
   20% of the codebase
   

   View Slide

4. Why large classes?
   ● Business critical
   ● Building trust
   ● Ramping up
   ● Code smells
   

   View Slide

5. Business criticality
   

   View Slide

6. Building trust
   Ask good questions? 󰤁
   

   View Slide

7. Ramping up (non-exhaustive)
   Database schema
   UML diagrams
   Debugger breakpoints
   Using the app
   Pairing with QA folks
   HTTP requests
   Logs
   IDE
   Directory structure
   

   View Slide

8. Syntax
   highlighting?
   

   View Slide

9. View Slide

10. View Slide

11. Graphs?
    Adam Rhodes / Unsplash
    

    View Slide

12. View Slide

13. Dependency
    Structure Matrix?
    

    View Slide

14. View Slide

15. Insights ● Identifiers are
    valuable
    ● We can’t ignore the
    network
    

    View Slide

16. Peter Naur, Programming as Theory Building (1/2)
    “... quality of the designing programmer’s work is related to
    the quality of the match between their theory of the problem
    and their theory of the solution.”
    

    View Slide

17. Peter Naur, Programming as Theory Building (1/2)
    “... quality of the designing programmer’s work is related to
    the quality of the match between their theory of the problem
    and their theory of the solution.”
    

    View Slide

18. Peter Naur, Programming as Theory Building (1/2)
    “... quality of the designing programmer’s work is related to
    the quality of the match between their theory of the problem
    and their theory of the solution.”
    

    View Slide

19. Peter Naur, Programming as Theory Building (1/2)
    “... quality of the designing programmer’s work is related to
    the quality of the match between their theory of the problem
    and their theory of the solution.”
    

    View Slide

20. Peter Naur, Programming as Theory Building (2/2)
    “Note that the quality of a later programmer’s work is related
    to the match between their theories and the previous
    programmer’s theories.”
    

    View Slide

21. Peter Naur, Programming as Theory Building (2/2)
    “Note that the quality of a later programmer’s work is related
    to the match between their theories and the previous
    programmer’s theories.”
    

    View Slide

22. Peter Naur, Programming as Theory Building (2/2)
    “Note that the quality of a later programmer’s work is related
    to the match between their theories and the previous
    programmer’s theories.”
    

    View Slide

23. Peter Naur, Programming as Theory Building (2/2)
    “Note that the quality of a later programmer’s work is related
    to the match between their theories and the previous
    programmer’s theories.”
    

    View Slide

24. Hand off ● Onboarding
    ● Documentation
    ● Tests
    ● Code comments
    ● Git history
    ● Working software
    

    View Slide

25. What helps? 1. Vocabulary
    2. Relationships
    3. Prior exposure to the
    problem domain
    

    View Slide

26. Misael Moreno Sam Glen Carrie Matthew Ansley All images are from Unsplash
    

    View Slide

27. observablehq.com
    

    View Slide

28. Edge bundling
    graph
    https://observablehq.com/@d3/bilevel-edge-bundling
    

    View Slide

29. Insights ● Identifiers are
    valuable
    ● We can’t ignore the
    network
    

    View Slide

30. Insights ● Identifiers are
    valuable
    ● We can’t ignore the
    network ✅
    

    View Slide

31. Vocabulary
    all the words used by a particular person, or all the words that exist in a particular language or subject
    — Cambridge Dictionary
    

    View Slide

32. Types ● void
    ● long
    ● StoryPost
    ● Int
    ● TextView
    ● AnimatorSet
    

    View Slide

33. Identifiers ● onShowCaption
    ● startReply
    ● animateChrome
    ● pauseProgress
    ● onMediaReady
    ● getResources
    

    View Slide

34. Identifiers → Words
    ● onShowCaption → on, show, caption
    ● startReply → start, reply
    ● pauseProgress → pause, progress
    ● onMediaReady → on, media, ready
    

    View Slide

35. Count frequency 😎
    Types
    ● StoryPost : 11
    ● TextView : 10
    Words
    ● on : 15
    ● get : 8
    

    View Slide

36. Insights ● Identifiers are
    valuable
    ● We can’t ignore the
    network ✅
    

    View Slide

37. Insights ● Identifiers are
    valuable ✅
    ● We can’t ignore the
    network ✅
    

    View Slide

38. Tooling demo 🥳
    

    View Slide

39. Refactoring ● Reduce complexity
    ● Improve structure
    ● Improve
    performance
    

    View Slide

40. Refactoring demo 🥳 🥳
    

    View Slide

41. https:/
    /github.com/redgreenio/tumbleweed
    

    View Slide

42. Your Code as a
    Crime Scene
    https://github.com/adamtornhill/code-maat
    

    View Slide

43. View Slide

44. Summary
    ● Vocabulary and relationships are the key to understanding a class
    ● Good questions,
    ○ Help find answers that are critical to maintaining the class
    ○ Help build trust
    ● You can safely refactor classes when,
    ○ You are improving the structure
    ○ Can use IDE-assisted refactoring actions
    ○ Can lean on the compiler and tighten the feedback loop
    

    View Slide

45. Questions?
    Email ragunath@redgreen.io
    Twitter @ragunathjawahar
    

    View Slide