principle-fix-root-causes
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseFix Root Causes
修复根因
When debugging, do not fix symptoms. Trace every problem to its root cause and fix it there.
Why: Symptom fixes accumulate. Each workaround makes the system harder to reason about, and the real bug remains. Root-cause fixes are slower upfront but reduce total debugging time.
Pattern:
- Reproduce first
- Ask "why" until you hit the root cause
- Do not add guards (adding a nil check to silence a crash is a symptom fix)
- If a workaround needs a paragraph-long comment to justify it, the code is wrong (fix the code, not the comment)
- Check for the pattern, not just the instance (grep for the same pattern, fix all instances)
- When stuck, instrument. Don't guess (add logging, read the actual error)
Restart bugs: suspect state before code
When something "fails after restart," suspect stale persistent state first: config files, caches, lock files, serialized state. If clearing a state file restores behavior, prioritize state validation as the fix.
调试时，不要修复症状。要将每个问题追溯至根本原因，并在根本原因处修复。
原因： 症状层面的修复会不断累积。每一种权宜之计都会让系统更难分析，而真正的 bug 仍然存在。根因修复前期较慢，但能减少总调试时间。
模式：
- 首先复现问题
- 不断追问“为什么”，直到找到根本原因
- 不要添加防护（添加 nil check 来掩盖崩溃属于症状修复）
- 如果一个权宜之计需要用一整段注释来解释其合理性，那么代码就是错的（修复代码，而不是注释）
- 检查这种模式，而不只是当前实例（grep 查找相同模式，并修复所有实例）
- 卡住时添加观测手段。不要猜测（添加 logging，读取实际错误）
重启后出现 bug：先怀疑状态，再检查代码
如果某项功能“重启后失败”，首先怀疑陈旧的持久化状态：配置文件、缓存、锁文件、序列化状态。如果清除状态文件即可恢复行为，应优先将状态验证作为修复方案。