程式設計師你為什麼這麼累 二 編碼習慣之介面定義

工作中，少不了要定義各種介面，系統整合要定義介面，前後台掉呼叫也要定義介面。介面定義一定程度上能反應程式設計師的程式設計功底。列舉一下工作中我發現大家容易出現的問題：

1. 返回格式不統一

同乙個介面，有時候返回陣列，有時候返回單個；成功的時候返回物件，失敗的時候返回錯誤資訊字串。工作中有個系統整合就是這樣定義的介面，真是辣眼睛。這個對應**上，返回的型別是map，json，object，都是不應該的。實際工作中，我們會定義乙個統一的格式，就是resultbean，分頁的有另外乙個pageresultbean

錯誤範例：

//返回map可讀性不好，盡量不要

public mapdelete(long id, string lang) 
// 成功返回boolean，失敗返回string，大忌
public object delete(long id, string lang) catch (exception e) 
}

一開始只考慮成功場景，等後面測試發現有錯誤情況，怎麼辦，改介面唄，前後臺都改，勞民傷財無用功。

錯誤範例：

//不返回任何資料，沒有考慮失敗場景，容易返工

public void update(long id, ***)

如lang語言，當前使用者資訊 都不應該出現引數裡面，應該從當前會話裡面獲取。後面講threadlocal會說到怎麼樣去掉。除了**可讀性不好問題外，尤其是引數出現當前使用者資訊的，這是個嚴重問題。

錯誤範例：

// （當前使用者刪除資料）引數出現lang和userid，尤其是userid，大忌

public mapdelete(long id, string lang, string userid)

一般情況下，不允許出現例如json字串這樣的引數，這種引數可讀性極差。應該定義對應的bean。

錯誤範例：

// 引數出現json格式，可讀性不好，**也難看

public mapupdate(long id, string jsonstr)

例如，新增介面一般情況下應該返回新物件的id標識，這需要程式設計經驗。新手定義的時候因為前台沒有用就不返回資料或者只返回true，這都是不恰當的。別人要不要是別人的事情，你該返回的還是應該返回。

錯誤範例：

// 約定俗成，新建應該返回新物件的資訊，只返回boolean容易導致返工

public boolean add(***)

附上resultbean，沒有任何技術含量：

＠data

public class resultbeanimplements serializable 
public resultbean(t data) 
public resultbean(throwable e) 
}

程式設計師你為什麼這麼累 七 編碼習慣之工具類規範

將來萬一要修改工具類的實現邏輯會很痛苦。static boolean isempty string str 它的方法的引數順序和之前spring的工具類是相反的，改起來非常容易出錯！第二個問題 這個方法有異常丟擲，必須宣告，這個改起來可要命了！結果你發現，乙個看上去很小的改動，改了幾十個檔案，每個改...

程式設計師，你怎麼這麼忙？為什麼天天熬夜加班？

說到最近的工作狀態，就只有忙碌能概括了，每天的時間基本都被工作塞滿，連看看新聞或者瀏覽部落格的時間都沒有，這個說法一點也不誇張，任務一來往往就是一直盯著電腦趕進度，等到做完再去看時間，差不多就已經是一兩個小時之後了，中間的這段時間就是一直沉浸在 裡 趕進度 連喝水可能都會忘記，絲毫沒有閒下來的時間。...

程式設計師轉行為什麼這麼難

儘管我在 大齡程式設計師的未來在何方 這篇文章裡比較樂觀地介紹了程式設計師保持競爭力的幾個方向，但現實依然是殘酷的 很多人將不得不離開軟體開發工作，轉型去從事其他職業。當你要這麼做時，就會感慨 想不到一切竟如此艱難！你不禁會想起李白老先生的詩 噫籲嚱，危乎高哉！蜀道之難，難於上青天！那麼，為什麼會這...