deadLine和榮譽感是最大推動力.

模組劃分,職責清晰. 做的好不好.

P7,P8要求 :
    規劃能力-抓手(有時候抓手都可以讓對應的同學完成. 頭腦風暴一下, 溝通,分贓會) : 設計原則,設計模式. 抽象出來幾個字. 需求方要求,準,快.

    需求分析能力:  人,系統, 流程,(功能性,非功能性),做一個最擔憂什麼? 技術方案,邊界互動,可靠性(巨集觀上的). 細節欄位(業務上的)

    優化能力: 結構化異常資訊的分析歸類,拆分能力.

架構師角度,面梳理,依賴工具見下治理,統籌安排.

普通開發角度,基礎知識

管理角度:流程管理,人員培養,內部 case 學習,每日值班制度.

軟性:

    職責明確能力:

    鼓勵能力:

高內聚,低耦合:

選型能力: - 可靠性,擴充套件性,可用性,壓測和效能瓶頸.

改進能力: 錯誤問題

比賽虛擬隊伍組織:

  0. 建了個群. 保證溝通渠道.

  1. 第一次開會, 明確目標:每個人都理解這些設計原則. 下週二來,然後定期跟蹤. 承諾和壓力

  2. 第二次達成一致,對各個細節點.見如下問題. 每個人領取兩個原則.原則模板,和框架.

  3. 最後一次,各自討論對方的,然後修改

  4. 上場,演練口號,夢想,目標等. 諮詢每個人是否已經看過.

補充: 分模組分層(facade或內聚業務隔離變化), 分層封裝(降低變數數).

         門面模式

1.職責單一

     結合工作經驗

     方法: A. 按業務流分.1.水平切分(更難,最後review下模組的存在是為了隔離變化.) 2.垂直切分. 3.支撐切分. (這種變化一個層面是多個系統比如多個支付方式,另外一個層面的內部業務的變化,比如費用)

              B. 按表分: 1.將一些表的業務剝離出去.如果夠穩定就剝離走.  2.將表拆分後將對應的業務剝離走.

     一旦切分完之後,下層要關注是否還需要和最上層溝通.( 分潤模組不需要直接呼叫訂單獲取費用,分析各種費用型別. 業務隔離,技術棧和繁瑣的費用型別隔離. 系統的作用遮蔽技術棧和業務變化. 雖然包含了兩種業務,但是遮蔽了變化)

     同一類的職責還是一個職責. 一個類一個方法,一個功能.

     按流程角度來職責,按垂直領域去單一. 最終到不可拆原則.

     介面隔離是方法(面向的是業務方),職責單一是目的

2.里氏替換(用的少)

    子類替換父類,而不是子類替換子類.  做法: 所有父類的方法都是final.

3.依賴倒置.

    結合業務知識: 把業務型別和支付型別變成類,介面化. 同時也引入了開閉原則.

   抽象不能依賴具體. 對於java來說介面不可能依賴具體.

   抽象類的方法必須是抽象的,通用的. 抽象具體是相對的.

   怎麼對倒置進行理解:   倒置 原來是直接依賴實現的,一開始就知道調什麼,現在不知道依賴的是什麼倒過來了.(現在服務端的介面都是通過autowired注入,一開始都是明確的,不屬於依賴隔離)

   怎麼對抽象進行理解:  商務單,普通單. 你可以抽象為訂單,也可以將發單動作抽象為一個介面. 更加符合單一原則.

   難點是什麼? 關鍵是要把共用的部分給抽象出來.

   blog.csdn.net/mariofei/article/details/23778661

   難點: 具體是對應著物, 抽象對應著行為業務功能.

            將具體的東西抽象出行為. 所有的都是service.

            http://www.uml.org.cn/sjms/201211023.asp#3

   實現一個很大的問題是 實現的依賴的實現也可以被上層看到.

4. 介面隔離原則..

    客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。

    實現不一定會隔離,可以依賴拆分後的介面.

    但是從單一職責的角度不應該同時依賴多個類,應該有組裝成組合組裝.

    難點: 隔離是相對呼叫者來說的. 介面隔離本身是方法,目的是為了對外面最小可見.

   介面隔離原則跟之前的單一職責原則很相似，其實不然。其一，單一職責原則原注重的是職責；而介面隔離原則注重對介面依賴的隔離。其二，單一職責原則主要是約束類，其次才是介面和方法，它針對的是程式中的實現和細節；而介面隔離原則主要約束介面介面，主要針對抽象，針對程式整體框架的構建

   介面隔離: 介面的含義是檔案,然後dubbo jar可以切成多隔.

   介面最小化,分開.不然實現類就要多實現.

   使用多個專門的介面比使用單一的總介面要好. 

   不動實現,介面拆分.

  舉例: 支付,先根據職責單元拆分成 微信支付,支付寶支付. 然後再拆成n個介面.

    虛線是依賴, 三角形是剪頭.

5.迪米特法則 ( 最少知道原則,減少對內部的瞭解. 自己補充:隔離變化原則.)

定義：一個物件應該對其他物件保持最少的瞭解。

方法:            1.  單一職責 能儘量避免這個.

                    2.  和直接朋友,不要越層呼叫.

                    3.  降低對外和整體的依賴度. 而不是個體之間的.

                  舉例: 快遞員.

                  網狀拓撲,變成星型拓撲. 銀行清算系統.

為什麼可以直接找對方: 每個功能不一樣, 有些service可以直接呼叫.

門面模式和調停者模式實際上就是迪米特法則的應用

6. 開閉原則:

   對擴充套件開發,對修改封閉.

  工程經驗:  將type欄位變成type介面.降低對內部的變化. 應對新的業務場景. 而不是採用門面模式,沒有依賴導致.

   評估方法:  1. 因變化導致變動行數越少

                    2. 因為變化導致變動程式碼行/原有程式碼行的比率.

                   3. 原有程式碼行數越多越差

  改進: 具有前瞻性,把變化的地方提取出來.可配置.