導讀
大家一提到程序員，首先想到的是以下標簽：苦逼，加班，熬夜通宵。但是，但凡工作了的同學都知道，其實大部分程序員做的事情都很簡單，代碼 CRUD 可以說毫無技術含量，就算什么不懂依葫蘆畫瓢很多功能也能勉強做出來，做個多線程並發就算高科技了，程序員這行的門檻其實還是比較低的。（這里說的是大部分，有些牛逼的，寫算法、jvm 等的請自動跳過）
是不是覺得很矛盾，一方面工作不復雜，一方面卻累成狗。有沒有想過問題出在哪里？有沒有想過時間都花在哪里呢？
對於我個人來說，編碼還是一個相對輕松的活（我是負責公司it系統的，沒有太多技術含量，數據量大，但並發量不大）。從工作到現在，我加班編碼的時間還是比較少的，我到現在為止每天還會編碼，很少因為編碼工作加班。
大家寫的東西都是一些 CURD 的業務邏輯代碼，為什么大家這么累，加班加點天天都是奮斗者？我從自己帶的項目中觀察中發現，大部分人的大部分時間都是在 定位問題 + 改代碼，真正開發的時間並不多。定位問題包括開發轉測試的時候發現問題和上線后發現問題，改代碼的包括改 bug 和因為需求變動修改代碼（后面專門開一貼說如何應對需求改動）。
所以說，simple is not easy。很多人就是因為覺得簡單，所以功能完成自己測試 ok 了就算了，沒有思考有沒有更加好的方式。歸根到底是因為編碼習慣太糟糕，寫的代碼太爛，導致無法定位頻繁修改頻繁出問題。（后面我會詳細講一些我看到的大部分的編碼問題。）
其實，對於個人來說，技術很重要，但是對於工作來說，編碼的習慣比技術更加主要。工作中你面試的大部分技術都不需要用到的。工作中，因為你的編碼習慣不好，寫的代碼質量差，代碼冗余重復多，很多無關的代碼和業務代碼攪在一起，導致了你疲於奔命應付各種問題。
所以我作為 SE，不管接手任何項目組，第一步就是制定代碼框架，制定項目組的開發規范，把代碼量減下去。事實上證明，這一步之后，大家的代碼量能下去最少1/3，后台的問題數下降比較明顯，大家的加班會比之前少。
給大家一個直觀的例子。下面是 controller 的一個刪除數據的接口，我來之前大家寫的這個樣子的（其實一開始比這個還差很多），功能很簡單，輸入一個對象id執行刪除返回是否刪除成功。大家有沒有覺得有什么問題？
@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang) {
Map<String, Object> data = new HashMap<String, Object>();
boolean result = false;
try {
// 語言（中英文提示不同）
Locale local = "zh".equalsIgnoreCase(lang) ? Locale.CHINESE : Locale.ENGLISH;
result = configService.delete(id, local);
data.put("code", 0);
} catch (CheckException e) {
// 參數等校驗出錯，這類異常屬於已知異常，不需要打印堆棧，返回碼為-1
data.put("code", -1);
data.put("msg", e.getMessage());
} catch (Exception e) {
// 其他未知異常，需要打印堆棧分析用，返回碼為99
log.error(e);
data.put("code", 99);
data.put("msg", e.toString());
}
data.put("result", result);
return data;
}
其實上面的代碼也沒有大問題。而我接手之后，我會開發自己的代碼框架，最后制定代碼框架交付的代碼如下（這是 controller 的部分）:
@PostMapping("/delete")
public ResultBean<Boolean> delete(long id) {
return new ResultBean<Boolean>(configService.delete(id));
}
用到的技術就是 AOP，也不是什么高深技術。怎么樣？代碼量就一行，特性一個都沒有丟。這就是我們項目組現在的 controller 的樣子！（如果恰好有我帶過的項目組的人，看到 ResultBean<> 應該很熟悉應該知道我是誰了）
所以說技術無所謂高低，看你怎么樣用。上面的代碼簡單說一下問題，第一，lang 和業務沒有什么關系，我后面的代碼框架去掉了（不是說我后面的代碼沒有這個功能，是把他隱藏起來對開發人員透明了，使用的技術就是 ThreadLocal ）。第二，前面那個代碼，實際上干活的就只有一行，其他都和業務代碼沒有一毛錢關系，我的代碼框架里面完全看不到了。
使用的技術真的很簡單，但是編碼效果非常好，因為大家不要因為使用的技術初級就覺得不重要！！使用這套框架后，大家再也不需要大部分時間都寫一些無聊的代碼，可以有更加多時間學習其他技術。說實話，在我項目組的開發人員都是比較幸運的，覺得能學到東西，不是像其他項目組，寫了幾年都是一樣的 CRUD 代碼，雖然我比較嚴厲，但是還是願意待在我項目組，畢竟加班比其他項目組少啊。
這就是我說的工作中，編碼習慣（或者說編碼風格）比技術更加重要。我工作了也有很長時間了，我覺得我個人價值最大的地方就是這些，技術上其實我懂的也和大家差不多，但編碼上我還是覺得可以超過大部分人的。后面我會把我們這些業務系統中大家編碼的問題一個一個寫出來，並把我的解決辦法分享出來。謝謝大家關注！
接口定義常見問題
工作中，少不了要定義各種接口，系統集成要定義接口，前后台掉調用也要定義接口。接口定義一定程度上能反應程序員的編程功底。列舉一下工作中我發現大家容易出現的問題：
返回格式不統一
同一個接口，有時候返回數組，有時候返回單個；成功的時候返回對象，失敗的時候返回錯誤信息字符串。工作中有個系統集成就是這樣定義的接口，真是辣眼睛。這個對應代碼上，返回的類型是map，json，object，都是不應該的。實際工作中，我們會定義一個統一的格式，就是 ResultBean，分頁的有另外一個 PageResultBean
錯誤范例
返回 map 可讀性不好，不知道里面是什么
@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang) {
}
錯誤范例
返回 map 可讀性不好，不知道里面是什么
@PostMapping("/delete")
public Object delete(long id, String lang) {
try {
boolean result = configService.delete(id, local);
return result;
} catch (Exception e) {
log.error(e);
return e.toString();
}
}
沒有考慮失敗情況
一開始只考慮成功場景，等后面測試發現有錯誤情況，怎么辦，改接口唄，前后台都改，勞民傷財無用功。
錯誤范例
不返回任何數據，沒有考慮失敗場景，容易返工
@PostMapping("/update")
public void update(long id, xxx) {
}
出現和業務無關的輸入參數
如lang語言，當前用戶信息 都不應該出現參數里面，應該從當前會話里面獲取。后面講ThreadLocal 會說到怎么樣去掉。除了代碼可讀性不好問題外，尤其是參數出現當前用戶信息的，這是個嚴重問題。
錯誤范例
（當前用戶刪除數據）參數出現lang和userid，尤其是userid，大忌
@PostMapping("/delete")
public Map<String, Object> delete(long id, String lang, String userId) {
}
出現復雜的參數
一般情況下，不允許出現例如 json 字符串這樣的參數，這種參數可讀性極差。應該定義對應的 bean。
錯誤范例
參數出現json格式，可讀性不好，代碼也難看
@PostMapping("/update")
public Map<String, Object> update(long id, String jsonStr) {
}
沒有返回應該返回的數據
例如，新增接口一般情況下應該返回新對象的 id 標識，這需要編程經驗。新手定義的時候因為前台沒有用就不返回數據或者只返回true，這都是不恰當的。別人要不要是別人的事情，你該返回的還是應該返回。
錯誤范例
約定俗成，新建應該返回新對象的信息(對象或者 ID )，只返回 boolean 容易導致返工
@PostMapping("/add")
public boolean add(xxx) {
//xxx
return configService.add();
}
很多人看了我的這篇文章程序員你為什么這么累？，都覺得里面的技術也很簡單，沒有什么特別的地方，但是，實現這個代碼框架之前，就是要你的接口的統一的格式 ResultBean，aop 才好做。有些人誤解了，我那篇文章說的都不是技術，重點說的是編碼習慣工作方式，如果你重點還是放在什么技術上，那我也幫不了你了。同樣，如果我后面的關於習慣和規范的帖子，你重點還是放在技術上的話，那是丟了西瓜撿芝麻，有很多貼還是沒有任何技術點呢。
總結
統一的接口規范，能幫忙規避很多無用的返工修改和可能出現的問題。能使代碼可讀性更加好，利於進行aop和自動化測試這些額外工作。大家一定要重視。
Controller規范
第一篇文章中，我貼了2段代碼，第一個是原生態的，第2段是我指定了接口定義規范，使用AOP技術之后最終交付的代碼，從15行到1行，自己感受一下。今天來說說大家關注的AOP如何實現。
先說說Controller規范，主要的內容是就是接口定義里面的內容，你只要遵循里面的規范，controller就問題不大，除了這些，還有另外的幾點.。
統一返回ResultBean對象
所有函數返回統一的 ResultBean/PageResultBean 格式，原因見我的接口定義這個貼。沒有統一格式，AOP 無法玩，更加重要的是前台代碼很不好寫。當然類名你可以按照自己喜好隨便定義，如就叫Result。
大家都知道，前台代碼很難寫好做到重用，而我們返回相同數據結構后，前台代碼可以這樣寫（方法 handlerResult 的重用）：
// 查詢所有配置項記錄
function fetchAllConfigs() {
$.getJSON('config/all', function(result) {
handlerResult(result, renderConfigs);
});
}
// 根據id刪除配置項
function deleteConfig(id) {
$.post('config/delete', {
id : id
}, function(result) {
console.log('delete result', result);
handlerResult(result, fetchAllConfigs);
});
}
/**
* 后台返回相同的數據結構，前台的代碼才好寫才能重用
* @param result： ajax返回的結果
* @param fn： 成功的處理函數（傳入data）
*/
function handlerResult(result, fn) {
// 成功執行操作，失敗提示原因
if (result.code == 0) {
fn(result.data);
}
// 沒有登陸異常，重定向到登陸頁面
else if (result.code == -1) {
showError("沒有登錄");
}
// 參數校驗出錯，直接提示
else if (result.code == 1) {
showError(result.msg);
}
// 沒有權限，顯示申請權限電子流
else if (result.code == 2) {
showError("沒有權限");
} else {
// 不應該出現的異常，應該重點關注
showError(result.msg);
}
}
ResultBean不允許往后傳
ResultBean/PageResultBean是controller專用的，不允許往后傳！往其他地方傳之后，可讀性立馬下降，和傳map，json好不了多少。
Controller只做參數格式的轉換
Controller做參數格式的轉換，不允許把json，map這類對象傳到services去，也不允許services返回json、map。寫過代碼都知道，map，json這種格式靈活，但是可讀性差（ 編碼一時爽，重構火葬場）。如果放業務數據，每次閱讀起來都十分困難，需要從頭到尾看完才知道里面有什么，是什么格式。定義一個bean看着工作量多了，但代碼清晰多了。
參數不允許出現Request，Response 這些對象
和json/map一樣，主要是可讀性差的問題。一般情況下不允許出現這些參數，除非要操作流。
不需要打印日志
日志在AOP里面會打印，而且我的建議是大部分日志在Services這層打印。
建議
Contorller只做參數格式轉換，如果沒有參數需要轉換的，那么就一行代碼。日志/參數校驗/權限判斷建議放到service里面，畢竟controller基本無法重用，而service重用較多。而我們的單元測試也不需要測試controller，直接測試service即可。
規范里面大部分是 不要做的項多，要做的比較少，落地比較容易。
原文：xwjie