大家眼中的程式設計師標籤

        作為初級的程式設計師，我們在平時專案中，接觸最多的就是業務層程式碼，每天就是CRUD，可以說沒有什麼技術含量，即使我們基礎很差，依葫蘆畫瓢很多功能也能夠勉強做出來。

         但是問題就來了：   工作很簡單，為什麼每天累成狗？？？

        通過在實驗室內全職加入兩個專案中，我總結出時間主要花在了   測試+定位問題+改程式碼。     真正開發的時間並不多，在專案中會經常遇到這樣的情況，一個簡單的功能模組，1-2個小時寫完了業務層的功能程式碼，但是需要5-6個小時去不停的定位問題該bug。這主要是因為自己寫的程式碼太lan。

         所以說， simple is not easy!!!

         無論是在實驗室專案中還是在公司中，很多人都會有這樣的心理：功能簡單，很快完成，簡單測試OK就算了，沒有思考有沒有更加好的方式。很多情況下會因為程式碼寫的太lan，程式碼質量差，很多無關的的程式碼和業務程式碼攪在一起，導致遇到問題時，會很難快速定位到出現問題的程式碼，浪費大量的時間。  這種情況下，你不加班才怪。。。。。。

      對於我個人來說，技術很重要，編碼更重要。因為很多情況下，在實際的專案中，在面試中問到的很多“高深”問題，在專案中很少用到。因此，對於業務開發來說，規範業務層程式碼，不但能夠減少程式碼量，快速定位問題，而且還能夠方面他人快速易懂閱讀程式碼。

        下面看一下這樣一段程式碼，這段程式碼是controller層的刪除資料的介面。

＠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;
}
 

         這段程式碼在專案中執行沒有什麼問題。但是如果拿著這段程式碼讓資深的Java開發人員看得話，會被滿臉的嫌棄。因為這寫得太lan。

  因此，如果將程式碼規範化，可以修改成：

＠PostMapping("/delete")
public ResultBean<Boolean> delete(long id) {
  return new ResultBean<Boolean>(configService.delete(id));
}

其實就簡單實用了一下AOP技術（也不是什麼高深的技術）。程式碼就一行，特性一個都沒有丟。

所以說，技術無所謂高低，最重要的是看你怎麼用。 “知道”、“懂”並不代表能夠很好的使用。其實在專案中的業務開發中，很多情況下使用到的技術都很簡單，但是一樣的業務開發人員，為什麼別人能夠受到部門老大的喜歡？

       接下來，我就從以下四個方面介紹在實際的專案開發中的編碼規範

                  1. 介面定義規範

                  2. controller規範

                  3. 異常處理規範

                  4. 工具類規範