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. 80/20 rule 80% of the value your software delivers to

    your customers comes from 20% of the codebase
  2. Ramping up (non-exhaustive) Database schema UML diagrams Debugger breakpoints Using

    the app Pairing with QA folks HTTP requests Logs IDE Directory structure
  3. 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.”
  4. 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.”
  5. 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.”
  6. 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.”
  7. 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.”
  8. 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.”
  9. 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.”
  10. 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.”
  11. Hand off • Onboarding • Documentation • Tests • Code

    comments • Git history • Working software
  12. Vocabulary all the words used by a particular person, or

    all the words that exist in a particular language or subject — Cambridge Dictionary
  13. Identifiers → Words • onShowCaption → on, show, caption •

    startReply → start, reply • pauseProgress → pause, progress • onMediaReady → on, media, ready
  14. 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