80/20 rule 80% of the value your
software delivers to your
customers comes from
20% of the codebase
Slide 4
Slide 4 text
Why large classes?
● Business critical
● Building trust
● Ramping up
● Code smells
Slide 5
Slide 5 text
Business criticality
Slide 6
Slide 6 text
Building trust
Ask good questions?
Slide 7
Slide 7 text
Ramping up (non-exhaustive)
Database schema
UML diagrams
Debugger breakpoints
Using the app
Pairing with QA folks
HTTP requests
Logs
IDE
Directory structure
Slide 8
Slide 8 text
Syntax
highlighting?
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Graphs?
Adam Rhodes / Unsplash
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
Dependency
Structure Matrix?
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
Insights ● Identifiers are
valuable
● We can’t ignore the
network
Slide 16
Slide 16 text
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.”
Slide 17
Slide 17 text
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.”
Slide 18
Slide 18 text
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.”
Slide 19
Slide 19 text
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.”
Slide 20
Slide 20 text
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.”
Slide 21
Slide 21 text
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.”
Slide 22
Slide 22 text
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.”
Slide 23
Slide 23 text
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.”
Slide 24
Slide 24 text
Hand off ● Onboarding
● Documentation
● Tests
● Code comments
● Git history
● Working software
Slide 25
Slide 25 text
What helps? 1. Vocabulary
2. Relationships
3. Prior exposure to the
problem domain
Slide 26
Slide 26 text
Misael Moreno Sam Glen Carrie Matthew Ansley All images are from Unsplash
Your Code as a
Crime Scene
https://github.com/adamtornhill/code-maat
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
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