1. 环境配置：“在我电脑上是好的！”
抓狂点：环境不一致导致代码行为诡异。
应对方法：
容器化：使用 Docker 和 Docker Compose。将环境（操作系统、依赖、配置）代码化，确保每个人在任何机器上启动的都是完全一致的环境。这是终极解决方案。
配置即代码：使用 Ansible, Chef, Puppet 等工具自动化环境配置。
版本化依赖：严格使用 package-lock.json, Pipfile.lock, Gemfile.lock 等锁文件，确保依赖树一致。
完善的 README：项目根目录必须有一个清晰、及时更新的 README.md，详细说明环境 setup 步骤。
2. 依赖地狱（Dependency Hell）
抓狂点：版本冲突，依赖无法安装。
应对方法：
信任锁文件：永远将锁文件提交到版本控制，不要手动运行 npm update 之类的命令来“碰运气”。
定期更新：设立周期（如每月），有计划地更新依赖，而不是等到积重难返。
使用虚拟环境：Python 的 venv，Node.js 的 nvm，Ruby 的 rvm/rbenv 可以隔离不同项目的依赖。
审查依赖：使用 npm audit，snyk 等工具定期检查安全漏洞，并评估是否真的需要引入某个庞大的库。
3. 神秘莫测的报错信息
抓狂点：错误信息不直观，无从下手。
应对方法：
修炼搜索大法：将错误信息的关键部分（去除项目特有的路径和变量）复制到 Google/Stack Overflow 搜索。你遇到的路，前人基本都走过。增加日志：在关键函数入口、出口和判断点添加清晰的日志（console.log, print, logger.info），让程序运行轨迹可视化。
使用调试器：熟练掌握 IDE 的调试器（断点、单步执行、查看变量），这是定位问题最强大的武器。
二分法排查：对于大段代码，使用“注释掉一半”的方法，快速定位问题范围。
4. 代码风格/规范之争
抓狂点：无休止的格式争论。
应对方法：
自动化格式化：使用 Prettier, Black, Gofmt, ESLint 等工具，在保存或提交时自动格式化代码。没有争论，机器说了算。
制定团队规范：在项目初期就约定好规范，并写入配置文件（如 .eslintrc, .editorconfig），让工具来约束。
CR聚焦逻辑：在代码审查中，大家约定俗成，对于格式问题由工具保证，重点审查代码设计、逻辑和潜在bug。
5. 薛定谔的Bug（Heisenbug/Bohrbug）
抓狂点：Bug难以稳定复现。
应对方法：
详尽的日志：这是最重要的手段。增加日志级别，在可疑区域输出更详细的状态信息。
录制和回放：对于前端Bug，使用浏览器插件录制操作序列；对于后端，尝试录制流量进行回放。
单元测试：为复现的Bug先写一个失败的单元测试，然后修复代码让测试通过。这既能修复Bug，也能防止未来回归。
心态放平：承认有些Bug就是“玄学”，暂时搁置，也许在解决其他问题时它会自己暴露出来。
6. 写文档和注释
抓狂点：抗拒、拖延，事后看不懂自己的代码。
应对方法：
“刚好够用”的文档：不追求大而全，但保证API文档、架构设计图、部署流程是清晰和最新的。
代码即文档：起一个好理解的函数名和变量名，比任何注释都强。注释应该解释“为什么这么做”（背后的意图或坑），而不是“做了什么”（代码已经表达了）。
将文档作为CR的一部分：将文档的更新作为代码合并的前提条件。
使用工具：Swagger/OpenAPI 用于API文档，JSDoc/Doxygen 用于生成代码文档。
