架構筆記九

　　有了好的架構還須要好的代碼，在編寫代碼前，咱們要區分代碼的類型，代碼分兩種：一個是表達業務邏輯的代碼，表達業務邏輯的代碼來源於現實生活的切分，是對生活的模擬和虛擬化，另外一種是對用戶提供訪問並保存業務邏輯運行結果的代碼，這裏有一個值得分析的名詞業務邏輯。

　　業務邏輯是指的是軟件代碼中的邏輯，不是現實生活中的邏輯，是除代碼縮進和計算順序調用以外的邏輯，如下用嚴格的順序調用來指代這種代碼。由於順序調用是計算機的特性，由編譯器來決定的，固然最本質的是由於咱們計算的基礎都是圖靈機。在現實生活中，順序調用也是邏輯，你們不要和咱們這裏說的業務邏輯相混淆。

　　Service裏面的代碼嚴格的計算順序調用的代碼不須要作單元測試，也很難作單元測試，由於這些代碼都須要和不少上下文打交道，因此代碼只要作連通性測試便可，因爲 Service 代碼簡單了，纔可讓咱們的開發人員投入更多的時間研究業務，畢竟這部分纔是軟件所真正服務的對象。Business 不訪問任何上下文，不訪問任何具體的設備，由於其餘地方沒有業務邏輯，因此一旦有問題，就能夠判定是 Model 的問題，單元測試確定能夠發現。若是單元測試沒有發現問題，那麼單元測試必定有問題。線上問題的模擬也就變得很是的簡單，單元測試也可以獲得進一步的補充。

　　在實際操做中，不能有邏輯，實際上和不少人的觀念是衝突的，認爲這個根本作不到。作到這一點須要不少的學習成本，可是必定能夠作獲得。當發現作不到的時候，能夠判定是業務的分析出了問題。好比不應合併的合併了，不應計算的計算了。這個問題必定有辦法解決的，作不到都是理由，無非是想早點把本身的工做結束罷了。雖然剛開始會比較困難，一旦把這個觀念變成自覺，開發的質量和效率立刻就能高好幾個級別

　　剛學習編程程序的時候，碰到一個問題，咱們老是想着怎樣實現某個功能，而不是思考整個軟件的架構問題，那時候只是以爲作架構沒什麼意思，還浪費時間，可是這樣的作法只會更加消耗咱們的時間成本，作一個小項目還能夠，遇到大項目成本就會指數級增長

參看：架構漫談