systematic-debugging（系统调试）

Systematic Debugging

Core Principle

Don't guess. Investigate systematically.

After 3 failed fix attempts, STOP and question the architecture.

Phase 1: Understand the Problem

Gather Information

1. What is the expected behavior?
2. What is the actual behavior?
3. When did it start failing?
4. What changed recently?

Reproduce Consistently

• Create minimal reproduction case
• Document exact steps to reproduce
• Identify if it's deterministic or intermittent

Check the Obvious First

• Is it plugged in? (Services running, dependencies installed)
• Are you in the right environment?
• Did you save the file?
• Is the cache cleared?

Phase 2: Root Cause Tracing

Backward Tracing Technique

1. Where does the bad value appear?
2. What called this with the bad value?
3. Keep tracing up until you find the source
4. Fix at source, not at symptom

Find Working Examples

• Locate similar working code in same codebase
• What works that's similar to what's broken?
• Compare against references

Identify Differences

• What's different between working and broken?
• List every difference, however small
• Don't assume "that can't matter"

Phase 3: Form Hypothesis

Scientific Method

1. Form a SINGLE hypothesis
2. Predict what you'd see if hypothesis is true
3. Design a test to verify
4. Run the test
5. If wrong, form new hypothesis based on new data

Don't Multi-Hypothesis

• One hypothesis at a time
• Test it completely before moving on
• Don't mix debugging approaches

Phase 4: Implement Fix

Write Failing Test First

• Test that reproduces the bug
• Test should fail before fix
• Test should pass after fix

Single Fix at a Time

• ONE change only
• No "while I'm here" improvements
• No bundled refactoring

Verify Completely

• Original test passes
• No other tests broken
• Issue actually resolved
• Edge cases covered

Phase 5: If Fix Doesn't Work

After Each Failed Attempt

1. STOP
2. Count: How many fixes have you tried?
3. If < 3: Return to Phase 1, re-analyze with new information
4. If ≥ 3: STOP and question the architecture

After 3+ Failed Fixes

Pattern indicating architectural problem:

• Each fix reveals new problems elsewhere
• Fixes require "massive refactoring"
• Each fix creates new symptoms

STOP and ask:

• Is this pattern fundamentally sound?
• Is this the right abstraction?
• Should this be redesigned?

Debugging Tools

Logging Strategy

// Add context to logs
console.log('[ComponentName] methodName:', {
  input,
  state: relevantState,
  timestamp: Date.now()
});

Binary Search Debugging

1. Add log at midpoint of suspect code
2. Determine if bug is before or after
3. Repeat until isolated

Rubber Duck Debugging

Explain the problem out loud:

• What should happen?
• What actually happens?
• What did I try?
• What assumptions am I making?

Common Pitfalls

Avoid These Mistakes

• Changing multiple things at once
• Assuming you know the cause
• Fixing symptoms instead of root cause
• Not verifying the fix actually works
• Not adding regression tests

Red Flags

• "It works on my machine"
• "It was working yesterday"
• "I didn't change anything"
• "That can't be the problem"