$30 off During Our Annual Pro Sale. View Details »

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

    ragunath@redgreen.io
  2. Agenda 1. Fundamentals 2. Tooling demo 🥳 3. Refactoring demo

    🥳
  3. 80/20 rule 80% of the value your software delivers to

    your customers comes from 20% of the codebase
  4. Why large classes? • Business critical • Building trust •

    Ramping up • Code smells
  5. Business criticality

  6. Building trust Ask good questions? 󰤁

  7. Ramping up (non-exhaustive) Database schema UML diagrams Debugger breakpoints Using

    the app Pairing with QA folks HTTP requests Logs IDE Directory structure
  8. Syntax highlighting?

  9. None
  10. None
  11. Graphs? Adam Rhodes / Unsplash

  12. None
  13. Dependency Structure Matrix?

  14. None
  15. Insights • Identifiers are valuable • We can’t ignore the

    network
  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.”
  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.”
  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.”
  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.”
  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.”
  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.”
  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.”
  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.”
  24. Hand off • Onboarding • Documentation • Tests • Code

    comments • Git history • Working software
  25. What helps? 1. Vocabulary 2. Relationships 3. Prior exposure to

    the problem domain
  26. Misael Moreno Sam Glen Carrie Matthew Ansley All images are

    from Unsplash
  27. observablehq.com

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

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

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

    network ✅
  31. Vocabulary all the words used by a particular person, or

    all the words that exist in a particular language or subject — Cambridge Dictionary
  32. Types • void • long • StoryPost • Int •

    TextView • AnimatorSet
  33. Identifiers • onShowCaption • startReply • animateChrome • pauseProgress •

    onMediaReady • getResources
  34. Identifiers → Words • onShowCaption → on, show, caption •

    startReply → start, reply • pauseProgress → pause, progress • onMediaReady → on, media, ready
  35. Count frequency 😎 Types • StoryPost : 11 • TextView

    : 10 Words • on : 15 • get : 8
  36. Insights • Identifiers are valuable • We can’t ignore the

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

    the network ✅
  38. Tooling demo 🥳

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

  40. Refactoring demo 🥳 🥳

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

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

  43. None
  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
  45. Questions? Email ragunath@redgreen.io Twitter @ragunathjawahar