Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Making sense of large Java and Kotlin classes

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).

Ragunath Jawahar

November 23, 2022
Tweet

More Decks by Ragunath Jawahar

Other Decks in Programming

Transcript

  1. Making sense of large Java
    and Kotlin classes
    Ragunath Jawahar
    [email protected]

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. Business criticality

    View full-size slide

  6. Building trust
    Ask good questions? 󰤁

    View full-size 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 full-size slide

  8. Syntax
    highlighting?

    View full-size slide

  9. Graphs?
    Adam Rhodes / Unsplash

    View full-size slide

  10. Dependency
    Structure Matrix?

    View full-size slide

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

    View full-size slide

  12. 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 full-size slide

  13. 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 full-size slide

  14. 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 full-size slide

  15. 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 full-size slide

  16. 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 full-size slide

  17. 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 full-size slide

  18. 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 full-size slide

  19. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. observablehq.com

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  34. Tooling demo 🥳

    View full-size slide

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

    View full-size slide

  36. Refactoring demo 🥳 🥳

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. 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 full-size slide

  40. Questions?
    Email [email protected]
    Twitter @ragunathjawahar

    View full-size slide