程序員你爲何這麼累？

你們一提到程序員，首先想到的是如下標籤：苦逼，加班，熬夜通宵。可是，但凡工做了的同窗都知道，其實大部分程序員作的事情都很簡單，代碼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<Boolean> delete(long id) { return new ResultBean<Boolean>(configService.delete(id)); }

 

用到的技術就是AOP，也不是什麼高深技術。怎麼樣？代碼量就一行，特性一個都沒有丟。這就是咱們項目組如今的controller的樣子！（若是剛好有我帶過的項目組的人，看到ResultBean<>應該很熟悉應該知道我是誰了）

 

因此說技術無所謂高低，看你怎麼樣用。上面的代碼簡單說一下問題，第一，lang和業務沒有什麼關係，我後面的代碼框架去掉了（不是說我後面的代碼沒有這個功能，是把他隱藏起來對開發人員透明瞭，使用的技術就是ThreadLocal）。第二，前面那個代碼，實際上幹活的就只有一行，其餘都和業務代碼沒有一毛錢關係，個人代碼框架裏面徹底看不到了。

使用的技術真的很簡單，可是編碼效果很是好，由於你們不要由於使用的技術初級就以爲不重要！！使用這套框架後，你們不再須要大部分時間都寫一些無聊的代碼，能夠有更加多時間學習其餘技術。說實話，在我項目組的開發人員都是比較幸運的，以爲能學到東西，不是像其餘項目組，寫了幾年都是同樣的CRUD代碼，雖然我比較嚴厲，可是仍是願意待在我項目組，畢竟加班比其餘項目組少啊。

這就是我說的工做中，編碼習慣（或者說編碼風格）比技術更加劇要。我工做了也有很長時間了，我以爲我我的價值最大的地方就是這些，技術上其實我懂的也和你們差很少，但編碼上我仍是以爲能夠超過大部分人的。後面我會把咱們這些業務系統中你們編碼的問題一個一個寫出來，並把個人解決辦法分享出來。初定議題以下：

1. 接口定義規範 點擊閱讀
2. controller規範 點擊閱讀（ResultBean的格式和緣由請看這裏）
3. 日誌規範 點擊閱讀
4. 異常處理規範 點擊閱讀
5. 國際化j和參數校驗規範 點擊閱讀
6. 工具類規範
7. 函數編寫建議 點擊閱讀
8. 配置建議 點擊閱讀

 

這些規範不是網上的哪些編程規範，說實話哪些又長又繁瑣，實踐中證實很難落地，我這裏的規範都比較少，一針見血，你看了便知。敬請期待！

 

====================GITHUB地址======================

全部的代碼細節都在已經上了github了，地址 xwjie/PLMCodeTemplate，歡迎加星。有問題歡迎提出。

 

我後面帖子都會收錄到專欄 個人java學習之路及習慣，請你們關注，謝謝！