大家一提到程式設計師，首先想到的是以下標籤：苦逼，加班，熬夜通宵。但是，但凡工作了的同學都知道，其實大部分程式設計師做的事情都很簡單，程式碼CRUD可以說毫無技術含量，就算什麼不懂依葫蘆畫瓢很多功能也能勉強做出來，做個多執行緒併發就算高科技了，程式設計師這行的門檻其實還是比較低的。（這裡說的是大部分，有些牛逼的，寫演算法、jvm等的請自動跳過）
是不是覺得很矛盾，一方面工作不復雜，一方面卻累成狗。有沒有想過問題出在哪裡？有沒有想過時間都花在哪裡呢？
對於我個人來說，編碼還是一個相對輕鬆的活（我是負責公司it系統的，沒有太多技術含量，資料量大，但併發量不大）。從工作到現在，我加班編碼的時間還是比較少的，我到現在為止每天還會編碼，很少因為編碼工作加班。
大家寫的東西都是一些crud的業務邏輯程式碼，為什麼大家這麼累，加班加點天天都是奮鬥者？我從自己帶的專案中觀察中發現，大部分人的大部分時間都是在 定位問題 + 改程式碼，真正開發的時間並不多。定位問題包括開發轉測試的時候發現問題和上線後發現問題，改程式碼的包括改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 delete(long id) { return new ResultBean(configService.delete(id)); } 用到的技術就是AOP，也不是什麼高深技術。怎麼樣？程式碼量就一行，特性一個都沒有丟。這就是我們專案組現在的controller的樣子！（如果恰好有我帶過的專案組的人，看到ResultBean<>應該很熟悉應該知道我是誰了）
所以說技術無所謂高低，看你怎麼樣用。上面的程式碼簡單說一下問題，第一，lang和業務沒有什麼關係，我後面的程式碼框架去掉了（不是說我後面的程式碼沒有這個功能，是把他隱藏起來對開發人員透明瞭，使用的技術就是ThreadLocal）。第二，前面那個程式碼，實際上幹活的就只有一行，其他都和業務程式碼沒有一毛錢關係，我的程式碼框架裡面完全看不到了。
使用的技術真的很簡單，但是編碼效果非常好，因為大家不要因為使用的技術初級就覺得不重要！！使用這套框架後，大家再也不需要大部分時間都寫一些無聊的程式碼，可以有更加多時間學習其他技術。說實話，在我專案組的開發人員都是比較幸運的，覺得能學到東西，不是像其他專案組，寫了幾年都是一樣的CRUD程式碼，雖然我比較嚴厲，但是還是願意待在我專案組，畢竟加班比其他專案組少啊。
這就是我說的工作中，編碼習慣（或者說編碼風格）比技術更加重要。我工作了也有很長時間了，我覺得我個人價值最大的地方就是這些，技術上其實我懂的也和大家差不多，但編碼上我還是覺得可以超過大部分人的。後面我會把我們這些業務系統中大家編碼的問題一個一個寫出來，並把我的解決辦法分享出來。初定議題如下：
介面定義規範 點選閱讀 controller規範 點選閱讀（ResultBean的格式和原因請看這裡） 日誌規範 點選閱讀 異常處理規範 點選閱讀 國際化j和引數校驗規範 點選閱讀 工具類規範 點選閱讀 函式編寫建議 點選閱讀 配置建議 點選閱讀
這些規範不是網上的哪些程式設計規範，說實話哪些又長又繁瑣，實踐中證明很難落地，我這裡的規範都比較少，一針見血，你看了便知。敬請期待！