Chapter 1: Refactoring Refactoring

1.1 What is refactoring?
1.2 Skill: What to Refactor?
__1.2.1 Code Smell Example
__1.2.2 Example of a rule
1.3 Culture: When to Refactor?
__1.3.1 Refactoring in Legacy Systems
__1.3.2 When should you not refactor?
1.4 Tools: (Safe) Refactoring Methods
1.5 Tools you need to get started
__1.5.1 Programming Language: TypeScript
__1.5.2 Editor: Visual Studio Code 1
__1.5.3 Version control: Git
1.6 Core Example: 2D Puzzle Game
__1.6.1 Practice is the only way to survive: The second codebase
1.7 Notes on Software in Real-World Environments
summation

Chapter 2: A Deep Dive into Refactoring

2.1 Improved readability and maintainability
__2.1.1 Code Improvement
__2.1.2 Maintaining code without changing what it does
2.2 Ensuring speed, flexibility, and stability
__2.2.1 Use composition over inheritance
__2.2.2 Additional code changes, not modifications
2.3 Refactoring and Daily Work
__2.3.1 Refactoring as a Learning Method
2.4 Defining a 'domain' in the software field
summation

Chapter 3: Splitting Long Code

3.1 First Rule: Why Five Lines?
__3.1.1 Rule: Five-line limit
3.2 Introducing Refactoring Patterns for Function Decomposition
__3.2.1 Refactoring Pattern: Extract Method
3.3 Function decomposition to match the level of abstraction
__3.3.1 Rule: Call or Pass, Do Only One
__3.3.2 Rule Application
3.4 Properties of a Good Function Name
3.5 Separating functions that do too much work
__3.5.1 Rule: if statements are placed only at the beginning of functions
__3.5.2 Rule Application
summation

Chapter 4: Handling Type Codes

4.1 Refactoring a simple if statement
__4.1.1 Rule: Do not use else in if statements
__4.1.2 Rule Application
__4.1.3 Refactoring Pattern: Replacing Type Code with Classes
__4.1.4 Migrating code to a class
__4.1.5 Refactoring Pattern: Migrating Code to a Class
__4.1.6 Inlining unnecessary methods
__4.1.7 Refactoring Pattern: Method Inlining
4.2 Refactoring long if statements
__4.2.1 Remove generality
__4.2.2 Refactoring Pattern: Method Specialization
__4.2.3 The only case where switch is allowed
__4.2.4 Rule: Don't use switch
__4.2.5 Removing if
4.3 Handling Code Duplication
__4.3.1 Can't we use abstract classes instead of interfaces?
__4.3.2 Rule: Inherit only from interfaces
__4.3.3 What is the duplication of code in class?
4.4 Refactoring complex if chain statements
4.5 Removing Unnecessary Code
__4.5.1 Refactoring Pattern: Delete and Compile
summation

Chapter 5: Merging Similar Code
5.1 Integrating Similar Classes
__5.1.1 Refactoring Pattern: Consolidating Similar Classes
5.2 Integrating Simple Conditions
__5.2.1 Refactoring Pattern: Combining if Statements
5.3 Integrating Complex Conditions
__5.3.1 Using Arithmetic Rules for Conditions
__5.3.2 Rule: Use pure conditions
__5.3.3 Applying Conditional Arithmetic
5.4 Integrating code between classes
__5.4.1 Introduction to UML class diagrams for depicting class relationships
__5.4.2 Refactoring Patterns: Introduction of the Strategy Pattern
__5.4.3 Rule: Don't create interfaces with only one implementation.
__5.4.4 Refactoring Pattern: Extracting Interface from Implementation
5.5 Integrating Similar Functions
5.6 Merging Similar Code
summation

Chapter 6: Data Protection

6.1 Encapsulation without getters
__6.1.1 Rule: Don't use getters and setters
__6.1.2 Applying the Rules
__6.1.3 Refactoring Pattern: Removing Getters and Setters
__6.1.4 Delete the last getter
6.2 Simple data encapsulation
__6.2.1 Rule: Do not use common affixes
__6.2.2 Applying the Rules
__6.2.3 Refactoring Pattern: Data Encapsulation
6.3 Complex Data Encapsulation
6.4 Removing invariants in a sequence
__6.4.1 Refactoring Pattern: Enforcing Order
6.5 Another way to remove enumerations
__6.5.1 Enumeration via private constructors
__6.5.2 Remapping numbers to classes
summation

Chapter 7: Working with the Compiler

7.1 Learning about the compiler
__7.1.1 Weakness: Halting problems limit what can be known at compile time
__7.1.2 Advantage: Reachability verification guarantees the return of a method.
__7.1.3 Advantage: Definite assignment prevents access to uninitialized variables.
__7.1.4 Advantage: Supports data encapsulation with access control
__7.1.5 Advantage: Type checker guarantees properties
__7.1.6 Weakness: Dereferencing null crashes the application.
__7.1.7 Weakness: Arithmetic errors cause overflow or corruption
__7.1.8 Weakness: Out-of-bounds errors crash applications.
__7.1.9 Infinite loops slow down your application.
__7.1.10 Weakness: Deadlocks and race conditions can lead to unintended behavior.
7.2 Using the Compiler
__7.2.1 Using the Compiler
__7.2.2 Don't fight the compiler
7.3 Trusting the Compiler
__7.3.1 Teaching the Compiler About Invariants
__7.3.2 Pay attention to compiler warnings
7.4 Trust only the compiler
summation

Chapter 8: Refrain from Commenting

8.1 Removing old comments
8.2 Removing commented code
8.3 Remove unnecessary comments
8.4 Replacing comments with method names
__8.4.1 Using Comments for Planning
8.5 Maintain comments documenting invariants
__8.5.1 Process Invariants
summation

Chapter 9: The Art of Code Deletion

9.1 The next era will be one of code erasure.
9.2 Deleting Code to Eliminate Complexity
__9.2.1 Technical ignorance due to lack of experience
__9.2.2 Technical waste due to time pressure
__9.2.3 Technical Debt by Environment
__9.2.4 Technical Obstacles to Growth
9.3 Code classification by intimacy
9.4 Deleting Code from Legacy Systems
__9.4.1 Strangler Fig Tree Pattern
__9.4.2 Using the Strangler Fig Tree Pattern to Improve Code
9.5 Deleting Code from a Frozen Project
__9.5.1 Setting the desired result as the default
__9.5.2 Reducing Waste with Spikes and Stabilization
9.6 Deleting a branch from version control
__9.6.1 Minimizing waste with branch limits
9.7 Deleting Code Documents
__9.7.1 Algorithm for determining how to document knowledge
9.8 Deleting test code
__9.8.1 Delete optimistic tests
__9.8.2 Pessimistic test deletion
__9.8.3 Fix or remove unstable tests
__9.8.4 Refactoring code to eliminate complex tests
__9.8.5 Speed-Up Testing Culture
9.9 Delete the settings code
__9.9.1 Scope the expected lifespan of the settings
9.10 Remove code for library removal
__9.10.1 Limiting dependencies on external libraries
9.11 Delete code from running function
summation

Chapter 10: Overcoming the Fear of Adding Code

10.1 Embracing Uncertainty: Taking Risk
10.2 Using Spikes to Overcome Fear
10.3 Specifying a usage time ratio to overcome fear of waste or risk
10.4 Incremental Improvement to Overcome Fear of Imperfection
10.5 How copying and pasting affects speed
10.6 Changes by addition through extensibility
10.7 Changes to ensure compatibility with previous versions
10.8 Changes due to addition of feature toggle (on/off)
10.9 Changes due to addition of 'Branching through Abstraction'
summation

Chapter 11: Following Code Structure

11.1 Classification of structures by scope and source
11.2 Three Ways to Codify Actions
__11.2.1 Coding Actions in Control Flow
__11.2.2 Coding Behavior into Data Structures
__11.2.3 Coding Behaviors into Data
11.3 Added code for exposing the structure
11.4 Observation instead of prediction, and use empirical techniques.
11.5 How to Ensure Security Without Understanding Code
__11.5.1 Ensuring Safety Through Testing
__11.5.2 Ensuring Safety Through Mastery
__11.5.3 Ensuring safety through tool support
__11.5.4 Ensuring safety through official certification
__11.5.5 Ensuring safety through fault tolerance
11.6 Exploiting unused structures
__11.6.1 Using Whitespace for Extraction and Encapsulation
__11.6.2 Using duplicate code for integration
__11.6.3 Using Common Affixes with Encapsulation
__11.6.4 Leveraging Runtime Types with Dynamic Execution
summation

Chapter 12: Avoiding Optimization and Generalization

12.1 Pursuit of Simplicity
12.2 Timing and Method of Generalization
__12.2.1 Avoiding generalization by minimizing implementation
__12.2.2 Integrating Similar Stability
__12.2.3 Eliminating unnecessary generalizations
12.3 When and How to Optimize
__12.3.1 Refactoring before optimization
__12.3.2 Optimization according to constraint theory
__12.3.3 Optimization using metrics
__12.3.4 Choosing Good Algorithms and Data Structures
__12.3.5 Using the cache
__12.3.6 Separating Optimized Code
summation

Chapter 13: Making Bad Code Identifiable

13.1 How to Deal with Bad Code
13.2 Separating clean code from legacy code
__13.2.1 Broken Windows Theory
13.3 How to find bad code
__13.3.1 Rules of this book: Simple and concrete code
__13.3.2 Code Smell: Complete and Abstract Code
__13.3.3 Cyclomatic Complexity: Algorithms (Objective)
__13.3.4 Cognitive Complexity: Algorithm (Subjective)
13.4 Rules for making code appear as bad code safely
13.5 How to make bad code look bad
__13.5.1 Using enumerations
__13.5.2 Using integers and strings as type codes
__13.5.3 Inserting magic numbers into code
__13.5.4 Commenting Your Code
__13.5.5 Adding spaces to code
__13.5.6 Grouping items by name
__13.5.7 Adding context to a name
__13.5.8 Creating a long method
__13.5.9 Passing many parameters to a method
__13.5.10 Using getters and setters
summation

Chapter 14: Conclusion

14.1 Looking back on the journey of this book
__14.1.1 Introduction: Motivation
__14.1.2 Part 1: Making It Specific
__14.1.3 Part 2: Broadening Your Horizons
14.2 Exploring Basic Philosophy
__14.2.1 Always find the smaller step
__14.2.2 Finding the basic structure
__14.2.3 Using Rules for Collaboration
__14.2.4 Prioritizing the team over the individual
__14.2.5 Favoring simplicity over completeness
__14.2.6 Using objects or higher-order functions
Journey after 14.3
__14.3.1 Journey to Microarchitecture
__14.3.2 Journey to Macro Architecture
__14.3.3 The Journey to Software Quality
summation

Appendix A: Installing Tools for Practice

Node.js
TypeScript
Visual Studio Code
Git
Setting up a TypeScript project
Build a TypeScript project
How to modify levels

What this book covers

◎ Characteristics of bad code
◎ How to safely improve code without understanding it
◎ Balancing optimization and code generality
◎ Use of an appropriate compiler
◎ Introduction of method extraction and strategy patterns and various other refactoring patterns
◎ Writing stable code that enables changes through code addition
◎ Writing code that doesn't require comments
◎ Real-world examples of great refactoring