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