<<架構漫談>>讀後感

  今天按照老師的要求，看了架構漫談1--9講，以爲受益良多，如下是我得點點讀後感：

（一）什麼是架構？

    架構的英文是Architecture，從定義上看，架構好像是一個過程，也不是很清晰。下面從架構的原因開始講解一下：爲了解決人類的延續的問題，天然而然就有男女羣居出現，這個時候就出現了分工了，男性和女性所作的事情就會有必定的分工，有了分工以後，人們的效率獲得了巨大的提升，因此這就產生了架構，因此文章也對這種現象總結了一些規律。

1. 必須由人執行的工做（不須要人介入，就意味着不須要改造，也就不須要架構了）

2. 每一個人的能力有限（每一個人都有本身的強項，我的的產出受限於最短板，而且因爲人的結構限制，同時只能專一於作好一件事情，好比雖然有兩隻眼睛，可是隻能同時專一於一件事物，有兩隻手，沒法同時作不一樣的事情。ps. 雖然有少部分人能夠左手畫圓右手畫框，可是不是廣泛現象）

3. 每一個人的時間有限（爲了減小時間的投入，必然會致使把工做分解出去，給擅長於這些工做的角色來完成，見2，從而縮短期）

4. 人對目標系統有更高的要求（若是知足於現狀，也就不須要進行架構了）

5. 目標系統的複雜性使得單我的完成這個系統，知足條件2，3（若是我的就能夠完成系統的提升，也不須要別的人參與，也就不須要架構的涉及，只是工匠，而且通常這個工做對時間的要求也不迫切。當足夠熟練以後，也會有必定的架構思考，但考慮更多的是如何提升質量，提升我的的時間效率）。

  

總結一下，什麼是架構，就是：

1. 根據要解決的問題，對目標系統的邊界進行界定。
2. 並對目標系統按某個原則的進行切分。切分的原則，要便於不一樣的角色，對切分出來的部分，並行或串行開展工做，通常並行才能減小時間。
3. 並對這些切分出來的部分，設立溝通機制。
4. 根據3，使得這些部分之間可以進行有機的聯繫，合併組裝成爲一個總體，完成目標系統的全部工做。

（二）如何作好架構之識別的問題·

  人們在處理問題的時候，都容易犯一個很大的問題，那就是在描寫概念的時候缺少主語。而咱們你們都心領神會的忽略這個主語，溝通的時候也都覺得你們都懂得對方說的主語是誰，結果你們都一塊兒犯錯誤。識別問題的一個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟着肯定了，再去討論問題纔有意義。

  因此爲了更好的解決問題，咱們要更好的理解概念的問題·，架構的問題，否則在一段時間忙完了發現本身作的是無用功，因此咱們要明白什麼是主體。

（三）如何作好架構之架構切分

  咱們要很是的清楚，全部的切分調整，都是對相關人的利益的調整。由於維護本身的利益，是每一個人的本性，是在骨子裏面的，咱們不能逃避這一點。在如今社會，每一個人都但願可以把本身的利益最大化，因此人們爲了工做更加的具備效率，天然須要舍掉一些本身不擅長的東西，用本身擅長的東西去換取別人擅長的東西。所以當人們認識到要主動的去切分一個系統的時候，毫無疑問，咱們不能忘掉利益這個原動力。全部的切分決策都不可以違背這一點，這是大方向。結合前一篇「識別問題」，一旦肯定了問題的主體，那麼系統的利益相關人（用現代管理學語言叫：stakeholder）就肯定了下來。所發現的問題，會有幾種狀況：

1. 某個或者某些利益相關人負載過重。
2. 時間上的負載過重。
3. 空間上的負載過重，本質上仍是時間上的負載過重。
4. 某個或者某些利益相關人的權利和義務不對等。

爲了在切分系統的時候，更加的平衡咱們須要要有着幾個原則：

1. 必須在連續時間內發生的一個活動，不能切分。好比孕婦懷孕，必需要10月懷胎，不可以切成10我的一個月完成。

2. 切分出來的部分的負責人，對這個部分的權利和義務必須是對等的。比方說媽媽10月懷胎，媽媽有權利處置小孩的出生和撫養，一樣也對小孩的出生和撫養負責。爲何必須是這樣呢? 由於若是權利和義務是不對等的話，會傷害每一個個體的利益，分出來執行的效率會比沒有分出來還要低，實際上也損害了總體的利益，這違背了提高總體利益的初衷。

3. 切分出來的部分，不該該超出一個天然人的負載。固然對於每一個人的能力不一樣，負載能力也不同，須要不斷的根據實際狀況調整，這實際上就是運營。

4. 切分是內部活動，內部無任怎麼切，對整個系統的外部應該是透明的。若是由於切分致使整個系統解決的問題發生了變化，那麼這個變化不屬於架構的活動。固然不少時候當咱們把問題分析的比較清楚的時候，整個系統的邊界會進一步的完善，這就會造成螺旋式的進化。但這不屬於架構所應該解決的問題。進化的發生，也會致使新的架構的切分。

在切分時候，這其實也就是一個建模的過程，爲了把大問題分解成小問題，減小人們的負擔量，令人們都更有效率的完成本身的工做。

（四）什麼是軟件

  在初期，軟件使用二進制編寫的，從硬件到軟件，成本都很是的高。隨着半導體技術的進步，硬件的成本愈來愈低，性能愈來愈高，甚至出現了摩爾定律：當價格不變時，集成電路上可容納的元器件數目，約每隔18-24個月增長一倍，性能提高一倍。軟件方面，爲了簡化難度，開始採用彙編，進一步出現了相似於人類的語言的高級語言，這使得人類能夠用相似於人的語言來和計算機溝通。軟件工程師慢慢愈來愈多，開發軟件的成本也愈來愈低。計算機就好像是一個只須要電，不須要休息的人，能夠無休無止的工做。人們愈來愈願意把原來只有人才能作的事情，交給計算機來作。結果就致使軟件愈來愈豐富，可以作的事情也愈來愈多，成本也愈來愈低。隨着軟件的規模的變大，作好一個軟件也變得愈來愈難了。早期的程序員寫程序，主要是爲了幫助本身研究課題。這些程序員熟練了以後，提升了本身的生產力，並發現還能夠幫助別人寫程序，慢慢軟件就變成了一個獨立的行業。

  因此軟件工程師就是實現這個模擬過程的關鍵人物，他必須先理解人是怎麼在平常生活中完成工做的，纔可以很好的把這些工做在計算機中模擬出來，軟件工程師自己的培養就比較難，同時行業知識也要靠時間的積累，這樣就遠遠超出了軟件工程師的能力了。因此軟件開發就開始有分工了。

  （五）軟甲架構到底要解決什麼問題

軟件實際上就是把現實生活模擬到計算機中，而且軟件是須要在計算機的硬件中運行起來的。要作到這一點須要解決兩個問題：

  1.業務問題

  2.計算機問題

  

這就是軟件比較複雜的地方，涉及到軟件自己的業務體系，和所虛擬的業務體系。根據以上的分析，所生成的架構，究竟那些算是軟件架構呢？

1. 軟件由於流量增大而分拆成不一樣的運行單元，在不一樣的機器上部署所造成的架構，屬於軟件架構。

2. 每一個運行單元爲了讓不一樣角色的人，好比前端，業務，數據存儲等可以並行工做，所分紅的代碼架構，也屬於軟件架構。

　　因此當咱們說軟件架構的時候，咱們必定要講清楚，究竟說的是部署的架構，仍是代碼的架構。軟件架構的落地，須要軟件的組織架構和流程來保障，離開了這個，軟件架構是一句空話。

（六）不要空設架構師這個職位，要給他實權

當咱們真正專一於別人的問題的時候，咱們本身的理想，抱負，對技術的追求都不算什麼了。這個時候就會真正的開始思考，別人究竟有什麼問題。架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的爲別人的利益服務，天然而然的架構師就擁有了強有力的影響力，確定會是一個leader。可是隻是民意上的leader是沒有用的，不能徹底發揮架構師的能量。因此架構師必須是一個組織的領導人，有權利調動這個組織的架構，纔可以更好的發揮架構師的做用，更好的把利益的調整落到實處。因此不少公司設了不少架構師的職位，可是並不具有調動組織架構的權利，那麼這個架構師的職位必定是形同虛設。架構師只可以經過創建某些流程來行使架構師的權利，好比強制架構review，反而會形成不少內部沒必要要的衝突，最終都會致使這些流程流於形式，得不償失。反過來，具有架構師能力的組織領導人，必定是一個很好的領導，這個組織必定是很健康向上的，由於每一個人的權利和義務就是比較均等的。而且這類領導對於組織成員權利和義務的對等情況會很是的敏感，會及時的調整組織架構，在問題發生以前就解決了。這樣這個組織就會具有更好的抗壓能力，可以更好的爲這個組織的客戶服務，這個組織的成員心裏必定都是比較平衡的，每一個人的能力都可以獲得比較好的發展。固然讀者可能又會說，這不是管理學的東西嗎？ 是的，但也是架構的問題。全部架構的核心就是組織架構。或者也能夠這樣說，一個合格的組織領導人，必定必須是一個合格的架構師。

  因此有人說架構師還須要技術嗎？不少人會問，特別是作軟件行業的，架構師是否是須要學習技術，甚至是學習語言？ 若是一個架構師還有這個困擾——就如問這個問題的人，說明目前還不具有作架構師的能力，或者說還不具有對本身領域——哪怕是技術領域——的自信，更別談業務領域了。

（七）從架構的角度想如何寫好代碼

重寫代碼，推翻原有架構，從新設計等等說法，來講明架構的進化。這實際上就是當初爲了完成任務，沒有充分思考所帶來的後果。這也並非架構進化的事情，而是我的對問題領域的逐漸深刻理解的過程。

軟件其實是對現實生活的模擬，虛擬化。這是一個很是重要的前提，直接決定了咱們的代碼應該分爲幾部分。結合每一個部署單元所承擔的責任，能夠明確的拆分爲兩個不一樣的責任：

1. 表達業務邏輯的代碼。不少人把這部分叫作Domain Logic，或者叫Domain Model。這部分實際是來源於生活的，必須保持和現實生活中的切分一致，並不是人爲的抽象而成。

2. 對用戶提供訪問並保存業務邏輯運行結果的代碼。計算機的狀態保存有一個缺陷，本機保留業務運行結果有很大的問題，通常都在外存儲設備上保存，也便於擴展。

這樣，就劃分紅了幾個責任：

1. Service就專一於user的需求，並組合Glue Code提供的服務完成需求。

2. Glue Code專一於組合business的調用，管理Business裏面對象的生命週期，而且經過Repository保存或加載Business的狀態

3. Business專一於實現業務的核心模型。

4. Repository專一於數據的保存，並和存儲設備一一對應。

（八）理清技術，業務和架構的關係

技術老是在人類解決對業務的要求不斷提升的狀況下產生，目的也是爲了獲取更大更好的利益。因此：

1. 技術是爲了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。

2. 有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都聽從人類的利益訴求——也就是業務。有人會問，不用鑽木取火了，可是弓弦加速轉動木棍還能夠用啊？ 沒錯，由於弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不同。可是兩種不一樣的技術，合理結合起來，會更好更有效率的解決業務問題。

　　因此技術與技術之間，有兩種關係：

1. 在解決同一個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。

2. 通常剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來講，技術纔是業務的enabler）。而後就會有提升效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其餘人（或者技術發明人本身）加以改進，這部分就會造成新的技術。

因此在咱們作工做的時候，公司裏的技術人員老是和業務人員發生衝突呢？ 這是由於技術人員不少時候關心的技術，和業務的主要目標每每不是直接對應的，業務也是負責某一部分的業務，也不是和業務的主要目標直接對應的，都是樹的分支節點（上文已經解釋了爲什麼會發生這種狀況）。只有直接解決業務問題的那個技術（或業務）—— 樹的根節點 —— 會和業務直接相關。因此一旦產生衝突，通常必須兩個根節點（通常都是領導）碰面才能解決問題，就是這個緣由——他們都知道業務主要目標。這也是爲何下層沒法理解上層，而上層都喜歡下軍令狀，要求下層執行。人只有儘可能去理解上層的問題才能作下層的分拆。因此架構師應該承擔起解決業務問題的這個角色來。因此，準確識別採用什麼技術的能力，也是架構師所要具有的能力之一。考慮的主要因素也是長期的成本和收益。