Error Code 錯誤碼該如何設計(下) – 良好的 Return Code 設計思路

上回我們提到Error Code 錯誤碼該如何設計(上) – 為什麼你不該隨意定義後，時隔許久，有人來訊詢問有沒有建議的設計，所以這邊來寫一下個人比較建議的Error Code 設計思路。

Error Code 的設計宗旨

Error Code 又可以稱為 Return Code ，白話來說，主要是為了再請求回傳時，能方便識別成功、失敗或者其他狀態所定義、使用的代碼，官方介紹可以看 維基百科 Error Code，這邊就不再贅述。

Error Code 是專案中不可或缺的，Error Code 的設計宗旨，就是方便相關人員能在第一時間識別的作用，可有效降低開發、維護上的問題常找時間。

Error Code 的基本設計，必須包含以下三種特性：

1. 具有唯一性
2. 可被擴充與分類
3. 可識別性

具有唯一性

Error Code , Return Code 代碼必須是唯一的，不可重複定義，更不可一碼具有多個意思。

可被擴充與分類

Error Code , Return Code 定義上並非雜亂無章，必須具有可歸類特性，且與需保留擴充空間，以供後續新增功能時新增相關定義。

可識別性

方便相關人員查找問題，可憑 Error Code, Return Code 區隔、判別錯誤 or 問題方向。

良好 Error Code 的設計思路

在單一系統、單一簡易架構下，只要具備上述三種特性，Error Code 基本上都是夠用的。

然而一個中大型專案，除了功能龐雜外，相關使用情境上的考量，也相對嚴謹且細緻，對應的狀態自然與小型專案無法比擬。

同時，系統與系統之間的串接與整合，幾乎是必然的會發生的事情，這時 Error Code ( Return Code ) 的設計就顯得格外重要，單純的具備基本特性的 Error Code，依據經驗長久走下去，顯然會不太合用。

所以，良好的 Error Code 設計思路，便是在原先的基礎上，加入一項要素項【產品編號概念】

產品編號概念

什麼是產品編號概念？

產品編號概念，又稱為商品編碼設計，用白話來說，就是將數字、英文代號混合使外，且代碼具有相關意義，想更加值觀，可以看看自己的身分證字號 or 手邊統一發票上的號碼，都是很直觀的範例。

產品編號設計特性

這裡我們來細講產品編號的設計概念。

產品編號的設計，基本由兩個要素組成， Source(來源) 與 Code (號碼)。

Source (來源)

可明確識別資料來源、出處或分類，舉凡時間(年,月)、地點、系統名、單位名、性別…等等，都可歸類在 Source (來源)。

Code(代碼)

不再是以單存的流水號，可依據需求進行設計，如身份證字號，代碼部分可被驗證或產品編號、統一編號，相關代碼可套用驗證公式進行有效性驗證。

例如圖一，有一串8位數的代號，你可以定義前三個是來源，後5個是產品的代碼。

更進一步，你可以依此設計一個商品代碼，且具備簡單的有效性驗證，如圖二。

圖二的範例，就是一個非常簡單的產品編號設計，設計上，在 Source 使用了地區、月份，在 Code 則以一個簡單的公式來產出號碼；同時，Source 與 Code中的條件，通常採用交集來查詢，確保編號唯一性。

或者你也可以加入年分，來進行生產年份進行管理，如下：

依據此規則，我們再來看一個範例，你可以設計一個符合自家產品的編號規格，其中包含了產地、系列、年份，如下:

對產品來說，廠商與經銷商，能在第一時間，對相關資訊做出識別，也因為採用交集，能進一步對產品進行驗證，初步避免了仿冒品大多使用流水號的作法。

當然，實際上的產品編號設計，為了防偽，公式不可能這麼簡單，但概念上大致都以此作為基礎，是個相當實用的設計概念。

使用產品編號概念設計 Error Code

在對產品編號設計有基本的理解後，這裡就來實際看一下，如何來著手規劃不同系統間的 Error Code。

我們直接來看圖：

圖五就是一個很簡單的範例，我們可以看到，Source中，定義了錯誤來自於哪個系統，也定義了錯誤訊息的分類。

Source 中系統明確的指出錯誤來自哪個系統，分類可幫助 RD 在第一時間，了解該錯誤屬於哪種類型，這樣能夠減少 debug 的時間，同時Code的部分，代碼保留了很大的擴充區塊，不用擔心會有不足的情況。

到這邊就算初步完成了簡單的設計。

當然，如果你只有單一系統，也可以簡化為以下設計:

在小系統中，上述設計其實已經非常夠用，當然這沒有一定的答案，終歸要依據系統需求、規模、複雜度而定。

Error Code 設計結論與建議

設計建議上，在設計 Error Code 中，除了上述提到的：

1. 具有唯一性
2. 可被擴充與分類
3. 可識別性
4. 使用產品編號概念設計 Error Code

這4點當中，最容易被忽略的，也是你必須要留意的，就是【日後的擴充性】，概念設計上相信大多人熟能生巧，但在可擴充性上，如果抓得太緊，很可能造成日後因為不夠用，導致為了整體性，需要全數更換的狀況。

畢竟 Error Code , Retrn Code 一旦定義，當系統龐大時，幾乎很難回頭，但也不必抓得太過寬鬆，個人建議，可以抓未來5年夠用的就可以了。