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 用于生成代碼文檔。