一個常被忽略，可辨識度卻很高的 SQA 判斷指標
在談軟體品質時，多數人直覺想到的是測試覆蓋率、Bug 數量、或系統穩定度。
但在實務經驗中，我逐漸發現一個非常具體、卻常被忽略的判斷方式：
一個系統是否曾被「認真設計過 Error Code」，往往比功能本身，更能反映它的品質成熟度。
這裡所指的，並不是單純用數字當索引的錯誤代碼，而是具有結構性與語意設計的 Error Code。
Error Code 何時成為一個「品質訊號」
我第一次真正意識到 Error Code 的設計價值，是在閱讀微軟的 source code 時。
在那些系統中，Error Code 並不是隨意定義的整數，而是透過 bit-wise AND / OR，善用 16 或 32 bit 的空間，將錯誤的來源、模組、類型與嚴重程度結構化地編碼進去。
那一刻我才意識到：
Error Code 本身，就是系統設計的一部分，而不是附屬品。
實務上非常常見的一個現象是：
當系統規模變大，但沒有一套清楚的 Error Code 與 Error Handling 機制時，團隊往往會把大量精力耗費在「找問題」本身，而不是解問題。
沒有 Error Code 的系統，真正的代價是什麼？
如果要簡單地總結缺乏結構性 Error Code 的影響，那會是：
判斷錯誤的時間被拉長，判斷方向的正確率被拉低，長遠來看，產品因為錯誤造成的客戶流失率會遠高於預期。
這類系統表面上看起來並非完全沒有錯誤處理：有 error message、有 log、有 exception call stacks，
甚至有一些防呆邏輯。
當問題發生時，團隊往往需要花大量時間釐清：
這是資料問題還是系統問題？
是哪個模組拋出的錯誤？
是已知問題的變形，還是全新的狀況？
因為錯誤沒有被結構化定義，所有人只能依賴經驗、猜測與反覆溝通來拼湊真相。
從 SQA 的角度來看，這是一個非常清楚的品質訊號：
系統從來沒有把「錯誤」當成一級設計對象。
Error Code 的本質，其實是設計者的成熟度
真正的分界線，往往不在於「有沒有 Error Code」，而在於：
設計者是否已經預期：問題一定會發生。
成熟的系統設計者，不會把錯誤視為例外，而是視為必然事件，一旦接受這個前提，Error Code 的角色就會徹底改變。
它不再只是給工程師 debug 用的工具，而是成為一種跨角色的資訊載體，用來在整條產品線中傳遞關鍵資訊。
也正因如此，Error Code 幾乎可以視為一個隱性的品質指標。
它反映的不是工程技巧，而是團隊是否思考過「問題發生之後，要如何一起面對它」。
Error Code 不只是為了錯誤，而是為了體驗
Error Code 常被誤解為事後救火工具，但實際上，它對使用者體驗的影響往往更直接。
Error Message 本質上只能「給人看」，而 Error Code 則是「給系統用的語意訊號」。
當錯誤是以結構化資訊表達時，前端與流程設計就有了更多可能性，能根據不同情境提供對應的引導，
而不是單純顯示一段錯誤文字。
從產品體驗角度來看，只剩下 Error Message 的系統，往往是把理解與修正的責任交回給使用者。
試想，你是希望系統給你一個常見的Toast告訴你"儲存發生錯誤!"。
還是給你一個引導視窗，告訴你沒有權限修改跟存儲這份文件，解決方案是什麼。
用戶的流失往往是無聲的，關注每一個可能影響用戶體驗的細節，會是產品勝出的關鍵。
結語
一個成熟的系統，並不是錯誤比較少，而是在錯誤發生之前，就已經想好要如何面對它。
而 Error Code，正是這種成熟度最具體、也最容易被忽略的表現之一。