Five Lines of Code: How and when to refactor

brief contents
contents
foreword
preface
Goal: The selected rules and refactoring patterns
Audience and roadmap
About the teaching
About the code
liveBook discussion forum
Bonus project
acknowledgments
about the author
about the cover illustration
1 Refactoring refactoring
1.1 What is refactoring?
1.2 Skills: What to refactor?
1.2.1 An example code smell
1.2.2 An example rule
1.3 Culture: When to refactor?
1.3.1 Refactoring in a legacy system
1.3.2 When should you not refactor?
1.4 Tools: How to refactor (safely)
1.5 Tools you need to get started
1.5.1 Programming language: TypeScript
1.5.2 Editor: Visual Studio Code
1.5.3 Version control: Git
1.6 Overarching example: A 2D puzzle game
1.6.1 Practice makes perfect: A second codebase
1.7 A note on real-world software
Summary
2 Looking under the hood of refactoring
2.1 Improving readability and maintainability
2.1.1 Making code better
2.1.2 Maintaining code . . . without changing what it does
2.2 Gaining speed, flexibility, and stability
2.2.1 Favoring composition over inheritance
2.2.2 Changing code by addition rather than modification
2.3 Refactoring and your daily work
2.3.1 Refactoring as a method for learning
2.4 Defining the “domain” in a software context
Summary
Part 1—Learn by refactoring a computer game
3 Shatter long functions
3.1 Establishing our first rule: Why five lines?
3.1.1 Rule: Five lines
3.2 Introducing a refactoring pattern to break up functions
3.2.1 Refactoring pattern: Extract method
3.3 Breaking up functions to balancing abstraction
3.3.1 Rule: Either call or pass
3.3.2 Applying the rule
3.4 Properties of a good function name
3.5 Breaking up functions that are doing too much
3.5.1 Rule: if only at the start
3.5.2 Applying the rule
Summary
4 Make type codes work
4.1 Refactoring a simple if statement
4.1.1 Rule: Never use if with else
4.1.2 Applying the rule
4.1.3 Refactoring pattern: Replace type code with classes
4.1.4 Pushing code into classes
4.1.5 Refactoring pattern: Push code into classes
4.1.6 Inlining a superfluous method
4.1.7 Refactoring pattern: Inline method
4.2 Refactoring a large if statement
4.2.1 Removing generality
4.2.2 Refactoring pattern: Specialize method
4.2.3 The only switch allowed
4.2.4 Rule: Never use switch
4.2.5 Eliminating the if
4.3 Addressing code duplication
4.3.1 Couldn’t we use an abstract class instead of the interface?
4.3.2 Rule: Only inherit from interfaces
4.3.3 What is up with all this code duplication?
4.4 Refactoring a pair of complex if statements
4.5 Removing dead code
4.5.1 Refactoring pattern: Try delete then compile
Summary
5 Fuse similar code together
5.1 Unifying similar classes
5.1.1 Refactoring pattern: Unify similar classes
5.2 Unifying simple conditions
5.2.1 Refactoring pattern: Combine ifs
5.3 Unifying complex conditions
5.3.1 Using arithmetic rules for conditions
5.3.2 Rule: Use pure conditions
5.3.3 Applying condition arithmetic
5.4 Unifying code across classes
5.4.1 Introducing UML class diagrams to depict class relations
5.4.2 Refactoring pattern: Introduce strategy pattern
5.4.3 Rule: No interface with only one implementation
5.4.4 Refactoring pattern: Extract interface from implementation
5.5 Unifying similar functions
5.6 Unifying similar code
Summary
6 Defend the data
6.1 Encapsulating without getters
6.1.1 Rule: Do not use getters or setters
6.1.2 Applying the rule
6.1.3 Refactoring pattern: Eliminate getter or setter
6.1.4 Eliminating the final getter
6.2 Encapsulating simple data
6.2.1 Rule: Never have common affixes
6.2.2 Applying the rule
6.2.3 Refactoring pattern: Encapsulate data
6.3 Encapsulating complex data
6.4 Eliminating a sequence invariant
6.4.1 Refactoring pattern: Enforce sequence
6.5 Eliminating enums another way
6.5.1 Enumeration through private constructors
6.5.2 Remapping numbers to classes
Summary
Part 2—Taking what you have learned into the real world
7 Collaborate with the compiler
7.1 Getting to know the compiler
7.1.1 Weakness: The halting problem limits compile-time knowledge
7.1.2 Strength: Reachability ensures that methods return
7.1.3 Strength: Definite assignment prevents accessing uninitialized variables
7.1.4 Strength: Access control helps encapsulate data
7.1.5 Strength: Type checking proves properties
7.1.6 Weakness: Dereferencing null crashes our application
7.1.7 Weakness: Arithmetic errors cause overflows or crashes
7.1.8 Weakness: Out-of-bounds errors crash our application
7.1.9 Weakness: Infinite loops stall our application
7.1.10 Weakness: Deadlocks and race conditions cause unintended behavior
7.2 Using the compiler
7.2.1 Making the compiler work
7.2.2 Don’t fight the compiler
7.3 Trusting the compiler
7.3.1 Teach the compiler invariants
7.3.2 Pay attention to warnings
7.4 Trusting the compiler exclusively
Summary
8 Stay away from comments
8.1 Deleting outdated comments
8.2 Deleting commented-out code
8.3 Deleting trivial comments
8.4 Transforming comments into method names
8.4.1 Using comments for planning
8.5 Keeping invariant-documenting comments
8.5.1 Invariants in the process
Summary
9 Love deleting code
9.1 Deleting code may be the next frontier
9.2 Deleting code to get rid of incidental complexity
9.2.1 Technical ignorance from inexperience
9.2.2 Technical waste from time pressure
9.2.3 Technical debt from circumstances
9.2.4 Technical drag from growing
9.3 Categorizing code based on intimacy
9.4 Deleting code in a legacy system
9.4.1 Using the strangler fig pattern to get insight
9.4.2 Using the strangler fig pattern to improve the code
9.5 Deleting code from a frozen project
9.5.1 Making the desired outcome the default
9.5.2 Minimizing waste with spike and stabilize
9.6 Deleting branches in version control
9.6.1 Minimizing waste by enforcing a branch limit
9.7 Deleting code documentation
9.7.1 Algorithm to determine how to codify knowledge
9.8 Deleting testing code
9.8.1 Deleting optimistic tests
9.8.2 Deleting pessimistic tests
9.8.3 Fixing or deleting flaky tests
9.8.4 Refactoring the code to get rid of complicated tests
9.8.5 Specializing tests to speed them up
9.9 Deleting configuration code
9.9.1 Scoping configuration in time
9.10 Deleting code to get rid of libraries
9.10.1 Limiting our reliance on external libraries
9.11 Deleting code from working features
Summary
10 Never be afraid to add code
10.1 Accepting uncertainty: Enter the danger
10.2 Using spikes to overcome the fear of building the wrong thing
10.3 Overcoming the fear of waste or risk with a fixed ratio
10.4 Overcoming the fear of imperfection by embracing gradual improvement
10.5 How copy and paste effects change velocity
10.6 Modification by addition through extensibility
10.7 Modification by addition enables backward compatibility
10.8 Modification by addition through feature toggles
10.9 Modification by addition through branch by abstraction
Summary
11 Follow the structure in the code
11.1 Categorizing structure based on scope and origin
11.2 Three ways that code mirrors behavior
11.2.1 Expressing behavior in the control flow
11.2.2 Expressing behavior in the structure of the data
11.2.3 Expressing behavior in the data
11.3 Adding code to expose structure
11.4 Observing instead of predicting, and using empirical techniques
11.5 Gaining safety without understanding the code
11.5.1 Gaining safety through testing
11.5.2 Gaining safety through mastery
11.5.3 Gaining safety through tool assistance
11.5.4 Gaining safety through formal verification
11.5.5 Gaining safety through fault tolerance
11.6 Identifying unexploited structures
11.6.1 Exploiting whitespace with extraction and encapsulation
11.6.2 Exploiting duplication with unification
11.6.3 Exploiting common affixes with encapsulation
11.6.4 Exploiting the runtime type with dynamic dispatch
Summary
12 Avoid optimizations and generality
12.1 Striving for simplicity
12.2 When and how to generalize
12.2.1 Building minimally to avoid generality
12.2.2 Unifying things of similar stability
12.2.3 Eliminating unnecessary generality
12.3 When and how to optimize
12.3.1 Refactoring before optimizing
12.3.2 Optimizing according to the theory of constraints
12.3.3 Guiding optimization with metrics
12.3.4 Choosing good algorithms and data structures
12.3.5 Using caching
12.3.6 Isolating optimized code
Summary
13 Make bad code look bad
13.1 Signaling process issues with bad code
13.2 Segregating into pristine and legacy code
13.2.1 The broken window theory
13.3 Approaches to defining bad code
13.3.1 The rules in this book: Simple and concrete
13.3.2 Code smells: Complete and abstract
13.3.3 Cyclomatic complexity: Algorithmic (objective)
13.3.4 Cognitive complexity: Algorithmic (subjective)
13.4 Rules for safely vandalizing code
13.5 Methods for safely vandalizing code
13.5.1 Using enums
13.5.2 Using ints and strings as type codes
13.5.3 Putting magic numbers in the code
13.5.4 Adding comments to the code
13.5.5 Putting whitespace in the code
13.5.6 Grouping things based on naming
13.5.7 Adding context to names
13.5.8 Creating long methods
13.5.9 Giving methods many parameters
13.5.10 Using getters and setters
Summary
14 Wrapping up
14.1 Reflecting on the journey of this book
14.1.1 Introduction: Motivation
14.1.2 Part 1: Making it concrete
14.1.3 Part 2: Widening the horizon
14.2 Exploring the underlying philosophy
14.2.1 Searching for ever-smaller steps
14.2.2 Searching for the underlying structure
14.2.3 Using the rules for collaboration
14.2.4 Prioritizing the team over individuals
14.2.5 Prioritize simplicity over completeness
14.2.6 Using objects or higher-order functions
14.3 Where to go from here
14.3.1 Micro-architecture route
14.3.2 Macro-architecture route
14.3.3 Software quality route
Summary
Appendix A—Installing the tools for part 1
Node.js
TypeScript
Visual Studio Code
Git
Setting up the TypeScript project
Building the TypeScript project
How to modify the level
index
Numerics
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
R
S
T
U
V
W