Error Code 錯誤碼該如何設計(上) – 為什麼你不該隨意定義

前言

聽友人說 Error Code 很簡單啊~
這好像很基本，但為什麼會寫這篇呢?

近剛執行完一個專案，不得不說，當你遇到一個沒有經驗、又不聽勸的後端人員，還要被迫開發通靈技能時，除了 codeing 到懷疑人生外，就只剩下想把指下的 Enter, E, J,A, Shift, ESC,.….等鍵，牢牢烙印在對方後腦杓的衝動了。

API Error Code 錯誤碼設計是許多初學者，在最初設計時最常遇見的一個坑，良好的錯誤碼設計，可以提升後期的維護效率，也能有效降低錯誤。

但這類的教學在網路上卻很少有人提到，也需要點經驗，也就導致許多初學者在設計階段，往往找不到一個好的範例，只能在網路上東看一個西抄一個，再加上自身的腦補來產出。

當新手產出了相關的錯誤碼，往往都很有自信，但實際用起來….卻容易把大家搞得烏煙瘴氣，後來的人更是難以接手與維護。

不廢話，先來講講常見令人頭疼的錯誤碼定義方法，可以大致分為以下:

1. 大雜燴的流水編號法 – 新手天賦技能
2. 一碼多解釋的通靈大法 – 被程式耽誤的通靈王

下面就一一來講述個別的症狀。

大雜燴的流水編號法 – 新手天賦技能

先來說說甚麼是『大雜燴的流水編號法』

這很簡單，依造流水號，一路往下編，想到什麼編什麼，一去不回頭，如 :

// Code : Message 對照表
{
    00001 : 刪除成功 , 
    00002 : 編輯失敗 , 
    00003 : 登入成功 , 
    00004 : 會員資料編輯成功 , 
    00005 : 分類新增失敗 , 
    00006 : 金流缺少資料 , 
    ……  , 
}

這也是新手最常見的做法，但缺點也顯而易見，沒有邏輯，不好管理。

當然這方法不一定是錯，用在開發獨立的小功能，倒還是堪用，但要放在一般專案、網站、CMS後台，雖然不至於讓功能錯誤，但後續管理起來，是挺亂的，也大大增加了debug 的時間。

如果你是初次嘗試….你還有救，多經歷幾個專案，你會逐漸找到脈絡

老人言

一碼多解釋的通靈大法 – 被程式耽誤的通靈王

看懂以下的定義方式，可能需要點特殊體質，如果你也這樣定義……你要轉職嗎?

// Code : Message 對照表
{
    001001 : 失敗 , 
    102001 : Email 資料未填寫 , 
    102001 : 資料格式錯誤 , 
    103001 : 資料未填寫 , 
    103050 : 資料格式錯誤 , 
    103001 : Email 資料未填寫 , 
    ……  , 
    487487 : 資料格式錯誤 , 
}

以上的定義，你可以看到，一組 code 被重複定義了多個解釋，假設當你接到 code 為 102001，你會開始疑惑，這到底是告訴你【格式錯誤】還是【資料未填】。

這樣的定義，除了讓前端工程師難以串接外，也同樣會造成後續管理困難，造成debug 時間過長。

期望沒有人可以見到這樣的定義。

如果你堅持這樣定義了……你要不要轉行，以免禍害他人

老人言

結論

錯誤碼設計，乍看之下簡單，但實際上還是需要一點實務經驗，至於怎麼設計才是比較好的做法呢，才可以讓後續更加好管理，之後會再寫一邊加以介紹。