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
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?
11. Graphs? Adam Rhodes / Unsplash
13. Dependency Structure Matrix?
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
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