紀錄工作經驗、相關知識,解決技術相關問題。

網站相關

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

前言

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

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

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

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

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

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

  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 時間過長。

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

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

老人言

結論

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

發表迴響