本系列從五個親身踩過的工程問題出發,記錄我如何從「我這邊明明正常」開始,查閱文件、保存證據、建立最小重現、重建事件軌跡,逐步搞懂需求定義、執行環境、資料契約、工具語意與非同步完成條件。這不是 30 天抓戰犯,而是把每一次踩雷整理成可重複使用的工程事故調查方法。It Works on My Machine 不是結論,而是事故調查與重新學習的起點:IDE 能跑,Terminal 卻失敗;語法完全合法,一個逗號卻悄悄把資料型別換掉;lint 與自動修正全數通過,ORM 查詢反而永遠撈不到資料;系統明明採用非同步 Pub/Sub,卻被要求立刻回答遠端指令成功了沒。
本篇是故事三的「踩雷」篇。 本篇要回答:一段語法完全合法的程式,如何在沒有任何錯誤訊息的情況下改變資料型別? 當時發生了什麼 整理一段多行賦值的程式碼時,行...
本篇是故事三的「查證」篇。 本篇要回答:懷疑資料在某處變形時,應該保存哪些證據? 當時發生了什麼 Day 11 的逗號事故有個殘酷的細節:debug 的前幾...
本篇是故事三的「重現」篇。 本篇要回答:錯誤型別為什麼能傳這麼遠?第一個把它擋下來的邊界在哪裡? 當時發生了什麼 Day 11 說錯誤在「很下游」才現形。這...
本篇是故事三的「理解」篇。 本篇要回答:逗號只是直接原因——是哪些條件讓一個字元的失誤,取得了橫穿整套系統的通行證? 當時發生了什麼 回看這場事故,我先後拿...
本篇是故事三的「內化」篇。 本篇要回答:怎麼把「修掉一個逗號」升級成「這一類無聲變形,在靠近源頭的地方就被攔下」? 當時發生了什麼 修掉逗號之後,第一版防再...
本篇是故事四的「踩雷」篇。 本篇要回答:所有工具都報告成功、程式正常啟動,為什麼查詢結果永遠是空的? 當時發生了什麼 一次例行的程式碼整理,跑了 lint...
本篇是故事四的「查證」篇。 本篇要回答:自動修正類事故需要保存哪些證據?以及——證據已經散失時,誠實的寫法是什麼? 當時發生了什麼 寫這個系列時,我很想把...
本篇是故事四的「重現」篇。 本篇要回答:一行「等價」的 Python 改寫,為什麼會改變 ORM 查詢的語意? 當時發生了什麼 Day 16 的事故軌跡,完...
本篇是故事四的「理解」篇。 本篇要回答:這場事故裡,工具、規則、流程與人,各自該記哪一筆帳? 當時發生了什麼 事故之後最順口的兩種結論,一種是「這工具有毒,...
本篇是故事四的「內化」篇。 本篇要回答:不因噎廢食、也不再裸奔——自動修正要怎麼用,才能既省力又不出事? 當時發生了什麼 Day 19 排除了兩種偷懶結論(...