優芽機構——三、4輪迭代總結

  首先說下《代碼大全》這本書，此書可做爲程序員的聖經，相信各個階段的程序員看此書的收穫都不會小。新手能夠經過此書來提升本身的專業技能、學習項目開發的流程。經驗豐富的程序員能夠經過此書來提升本身的代碼質量，檢查本身的不足和bug。

  但因爲此書不少都是理論上的知識，具體還須要本身在工做上和實踐中多敲代碼多體會。與此書配套的書還包括《重構》、《設計模式》、《算法導論》等。

  此輪的迭代收穫最大的就是編寫代碼的質量，從三個方面入手：能夠工做的類、高效的子程序和防護式編程。

  1、能夠工做的類：

      看完《代碼大全》發現本身之前寫的類幾乎都是面向過程在思考，並不屬於OOP的思想。首先，類做爲現實生活中的對象的映射，應該是被看作總體，沒多餘或者不屬於此對象的元素。比如一匹馬不可能有翅膀，因此「馬」這個對象若是想上天至少須要兩個對象——「飛機」和「馬」。可是原來寫代碼的時候經常會在「馬」這個類中加上「飛機」的元素，正常應該寫兩個類，而後調用。

      一個高質量的類的內聚性必定很是好，沒有多餘的元素，也沒有缺乏的元素，不須要將它拆開，造成一個完整的抽象。

2、高效的子程序

     若是說類是一個工廠的話，那子程序就是工廠上的每一個機器，一個機器僅僅負責一件事。

     此輪迭代中，針對緩存進行了很大部分的優化，其中須要：一、用戶的菜單從緩存中獲取，二、若是獲取不到須要進數據庫load數據，三、而後放入緩存，四、再從緩存中獲取。

     之前本人寫的代碼會在一個子程序中將234的具體細節所有實現，這樣寫雖然功能實現了，可是代碼質量卻很是低：

一、很不利於閱讀。程序實際上是給程序猿看的，根本不是給機器看的。臃腫的代碼交給其它程序猿的話，對方極可能很難看懂。

二、不利於維護。不少的功能放在一塊兒，若是其中某一塊出現問題，那極可能也會牽扯帶這個子程序其它的流程。

三、能夠說不符合OOP的思想，由於沒有一個機器能夠直接造出一臺汽車（原諒本人大學是機械專業的）。

     後面修改代碼，具體的細節改爲：一、用戶的菜單從緩存中獲取，二、從數據庫load數據，三、將數據放入緩存，四、從緩存中取數據。好處有如下幾點：

 一、這樣代碼結構很清晰，映射出編寫此程序的程序員的思惟也很清晰，閱讀人員能夠很快接受。

二、符合oop的思想，這些子程序每個都只負責處理一件事，而且這些子程序很獨立，即便脫離這個類，仍然可以保持本身的語義，不會由於環境變化而致使語義發生變化。

三、維護方便。若是某個地方出問題就只須要修改某一個子程序，不須要修改其它的部分，減小維護量。

3、防護式編程

     許多的編程都應該按照此思想去寫，這樣才能減小崩潰的機率，讓編寫出的程序足夠健壯。

     

private List<String> getOrgMenuIdsFromCache(String orgId) {
    if (StringUtils.isEmpty(orgId))
        return null;
    //將數據庫中的menuIds放入緩存，再返回這個緩存的menuIds
    String menuIds = GlobalCacheUtil.getVarStringValue(OrgUtil.getOrgMenuIdsCacheName(orgId));
    if (null == menuIds || StringUtils.isEmpty(menuIds))
        menuIds = OrgUtil.getOrgMenuActionCache(orgId);
    try {
        return JSON.parseArray(menuIds, String.class);
    } catch (Exception e) {
        logger.error(menuIds);
        logger.error("JsonUtil 解析json獲取 data失敗");
    }
    return null;
}

   以上這段代碼，很好的保持這種風格，在可能出現錯誤的位置都進行了判斷。若是在此處出錯也不會對整個系統產生什麼大的影響。

    固然，從結構的和風格上來看，代碼仍是有不少不足，好比子程序過長、不夠緊湊、用的方法不夠嚴謹、沒有注意高扇入低扇出的要求等等。在之後的工做中會更加嚴謹的對待代碼的編寫。