學習【聊聊框架】筆記

目錄

 

第一章 生命週期

第二章 時間

第三章 爲什麼產生架構

第四章 什麼是架構

第五章 架構和樹

第六章 概念

第七章 生命是抽象

第八章 識別困難

第九章 切分的原則

第十章 架構和流程

第十一章 什麼是架構師

第十二章 什麼是軟件

第十三章 軟件的生命週期

第十四章 什麼是軟件架構

第十五章 什麼是軟件架構師

第十六章 業務 、架構和技術三者的關係

第十七章 軟件研發

第十八章 軟件的架構拆分

第十九章 如何寫好代碼

第二十章 單元測試

第二十一章 軟件架構和麪向對象

第二十二章 軟件架構與設計模式

第二十三章 軟件架構和軟件框架、

第二十四章 軟件運維

第二十五章 軟件訪問生命週期

第二十六章 軟件架構和大數據

第二十七章 軟件架構和建築架構

第二十八章 交易

第二十九上 產品

第三十章 用戶

第三十一張 訂單

第三十二章 交易系統

第三十三章 事務


第一章 生命週期

  •     非核心生命週期一旦拆分出來以後,往往就變成一個通用的服務,反而獲得了更大的生命力,不再侷限於原有的大的生命週期。對非核心生命週期的掌握,慢慢也就成爲了一個一個的職業。
  •     而原有的大生命週期則變得更加精簡,可以更加專注一自己的核心生命週期活動,以節省更多的時間。

第二章 時間

第三章 爲什麼產生架構

第四章 什麼是架構

    1.架構產生的條件

  •         必須要由執行的工作
  •         每個人的時間有限
  •         對目標要求有更高的要求
  •         對目標系統的複雜性使得單個人完成是會受限於時間
  •         建築構架按照人類生命週期的需求,對地球上的空間進行切分,並通過門窗、地基等技術,保持和地球以及空間的有機溝通。
  •         人類的必要生命週期活動,如喫、睡等,是和時間相關的,自然也會根據人的生命週期規律按照時間來劃分內部空間。

    2.什麼是架構

  •         根據要解決的人類的問題,對目標系統進行定界
  •         圍繞目標系統核心生命週期進行切分
  •         對這些切分出來的部分,確定各自的生命週期及其主體,以及負責的角色
  •         在這些拆分出來的非核心生命週期和核心生命週期之間建立溝通機制,使得只寫核心生命週期能夠圍繞核心生命週期,通過樹狀架構組裝起來成爲一個整體,共同爲核心生命週期做出貢獻。

第五章 架構和樹

第六章 概念

  •     每一個概念實際上所解決的,還是人們的某個特定的問題,人們把解決問題的解決方案,給定了一個名字,這個名字就是對應的某個特定的概念。

第七章 生命是抽象

  •     因爲解決的問題不一樣,兩個概念的個性不是完全一樣的,所以我們不能用抽象來定義一個事物。抽象實際上是一個分類的過程,抽取出事物中人們所關心的一些特徵,並且不同的人抽取的側重點是不一樣的,甚至完全不相同。

第八章 識別困難

  •     識別問題的一個最重要的前提就是要搞清楚:是誰的問題,也就是要先明確問題的主體是誰。主體搞清楚,問題的邊界也就跟着確定了,再去討論問題纔有意義。
  •     任何找上架構師的問題,絕對不是真正的問題。
  •     架構師都要有這個自覺:發現問題永遠比解決問題更加重要。

第九章 切分的原則

  •     人們在人類社會生存、立足、做人的基本道德和原則:先要付出纔能有收穫。
  •     架構切分的原則:

        1.被切分的生命週期,如果必須要生命週期的主體在連續時間內持續執行,而且不能掛起被打斷並更換生命週期主體的話,就不能切分出去。
        2.每個生命週期的負責人,對所負責生命週期的權利和義務必須是對等的。
        3.切分出來的生命週期,不該超出一個自然人的負載。
        4.切分是內部活動,內部無論怎麼切,對整個系統的外部都應該是透明的。

  •     總結:

        1.架構的切分的導火索是人的負載太重,也就是時間不夠。
        2.架構的切分實際上是對利益相關人的利益進行切分或合併,是的每一個利益相關人員的權責是對等的,每一個利益相關人可以爲自己的利益負責。
        3.架構切分是最終結果都會體現在組織架構上,只有這樣才能夠讓架構落地並推進。
        4.架構切分的結構一定是一個樹狀,這也是爲什麼會產生分層。

第十章 架構和流程

第十一章 什麼是架構師

  •     架構的目的是爲了增長。

第十二章 什麼是軟件

第十三章 軟件的生命週期

  •     軟件的整個生命週期也會發生切分,從而形成兩個子生命週期:軟件開發生命週期和軟件運行生命週期。
  •     從另一個角度來說,人們真正需要的是軟件啓動後爲我們帶來的服務,也就是說軟件運行生命週期纔是人們真正需要軟件的地方。
  •     圍繞着軟件的生命週期,還會切分出來很多其他的非核心生命週期:

        1.軟件的開發生命週期。(內部還會發生切分,如需求生命週期、代碼開發生命週期、測試生命週期等)。
        2.軟件的運行生命週期。(a.軟件的訪問生命週期。b.軟件的功能生命週期。c.軟件的監控生命週期。)

  •     從軟件運行的生命週期的角度來說,一個可運行的獨立部署單元纔算是一個軟件。
  •     另一個學習的判斷標準就是:學習一個東西如果只是能聽懂,還不算學會;如果自己能夠按照所學的執行,也才學會了一半;如果能夠把自己所學的東西用自己的語言表達出來,讓別人聽懂,這纔算纔不多學會了。
  •     而想對軟件和計算機之外的行業業務進行模擬,軟件工程師還要對改業務所在的行業的專業知識進行一定的積累,並要超越聽懂和能執行兩個階段,才能用另外一種語言,也就是計算機語言表達出來。這是一個相當高的要求。
  •     無論是哪種切分或分工模式,即軟件開發模式,其目標都是達到軟件開發的增長。

第十四章 什麼是軟件架構

  •     生成的架構如下:

        1.在軟件開發生命週期中採用的人員越來越多,就會形成軟件開發團隊的組織架構。
            a.爲了讓業務在軟件中實現並落地,並便於用戶對軟件的訪問,需要前端人員、業務代碼人員、存儲人員等不同技巧的人同時工作,並把代碼進行切分,形成代碼的架構。

  •        從分層的角度進行思考的時候,要千萬注意不要破壞樹的架構。有樹纔會有分層,有分層卻不一定有樹。

            b.爲了完成業務的工作,需要把識別出來的業務架構和支持業務的組織架構,以及業務運作的核心生命流程,用代碼表述出來。
        2.在軟件的運行週期中,當軟件的流量越來越大時,慢慢會超出軟件所在機器的能力。
            離開了組織架構,任何軟件架構設計都是紙上談兵,因爲軟件的核心生命週期就是架構的執行。

第十五章 什麼是軟件架構師

  •     具備架構師頭銜的人並不一定是架構師。
  •     架構師的核心在於架構的執行,軟件架構師必須是一個組織的領導人,有權利調動這個組織的架構,才能更好地發揮架構師的作用,才能夠把軟件開發生命週期、軟件運行生命週期和業務生命週期的拆分落實執行。
  •     軟件開發團隊的組織領導人其實就是架構師,只是沒有這個頭銜而已,真正的架構師並不一定具備架構師的頭銜。
  •     人類架構的核心就是組織架構,正確的組織架構才能保證架構的執行。
  •     要想做好架構師的工作,就要向大自然學習,這樣才能夠認識到事務自身的生命週期,並能夠去順應事務自身的生命週期的規律來進行拆分,以達到增長的目的。
  •     如果把業務認爲是硬幣,則可以認爲架構和技術是硬幣的兩面,架構和技術共同組成了業務。

第十六章 業務 、架構和技術三者的關係

  •     什麼是技術?

        通過人爲創造條件,讓指定的規律按照人類的意願發生,這就是技術。

  •     什麼是業務?

        所謂業務,就是要解決人類的問題,目的是支撐人類自身的生命週期,使人類獲得利益。

  •     業務是核心,技術是解決業務問題的工具,而框架是讓業務長大的組織方法。
  •     架構需要用技術來實現拆分,而技術需要架構來合理組織,提升效率。
  •     修煉的過程就是自己的思維觀念變成和作者一致的過程。
  •     要想付出纔能有收穫,這是這個世界運行的準則。

第十七章 軟件研發

  •     編寫軟件是從科學計算中拆分出來的,變成一個通用服務,成爲一個獨立的職業,具有獨立的生命週期。
  •     這就是軟件這個新技術的出現,導致了新的社會分工和新的架構拆分。
  •     軟件和業務最終還是要合體的。
  •     軟件架構師並不一定是具備架構師頭銜的那位,但一定是軟件研發團隊組織的領導。
  •     軟件開發業務本身也是軟件的一個業務。
  •     組織軟件工程師進行有效的分工,形成軟件開發團隊的組織架構。
  •     爲了減輕軟件工程師的負擔,要把軟件開發過程中的非核心生命週期拆分出來,形成軟件開發本省的業務架構,並通過自動化來提升軟件工。
  •     架構師本身也是架構師的一個業務,也需要架構拆分,形成不同領域的架構師。
  •     軟件工程師負責建設,軟件架構師負責組織。

第十八章 軟件的架構拆分

  •     軟件開發團隊拆分:

        一個業務團隊對應一個軟件開發團隊,這種方式會讓軟件開發團隊的組織也形成一棵組織樹,並且這棵樹和業務團隊的組織樹是匹配的。

  •     軟件拆分:

        一個軟件開發團開發一個軟件。組織形成的還是一棵樹。軟件和軟件之間的關係,反映的就是組織和組織之間的關係,一一對應,還是一棵樹。

  •     從軟件團隊到人,從人到組件,形成的還是一棵樹。軟件和組件,組件和組件之間,形成的也是一棵樹。
  •     重用訪問通道的結果,既損傷用戶的利益,也損傷軟件的利益,還會損傷軟件開發團隊和企業的利益。

第十九章 如何寫好代碼

  •     內聚就是確保一個事物的生命週期是完整的,而不是分裂的。所謂完整,就是指一個生命週期的主體,從生到死之間的整個過程,所發生的行爲和狀態是積累在一個主體上的。
  •     直接把某些業務生命週期的代碼拆分到另外的一個軟件中,並把相應的服務代碼、管理者代碼和存儲代碼一起拆分過去。這個拆分方式就形成了新的軟件,而對於原軟件的影響僅僅是對被拆除過去的業務調用方式發生了變化而已,從本地調用變成了服務調用。

第二十章 單元測試

  •     只要出現了模擬,單元測試就開始失敗了。
  •     通過別人的反饋保持的興趣會比較短,因爲很多時候別人的反饋其實處於禮貌。而自己對自己所做事情的反饋,纔是至關重要的,知識形成興趣的最終的因素。

第二十一章 軟件架構和麪向對象

  •     面向過程反映的是生命週期按時間推進的特質,而面向對象反映的則是事務生命週期活動內聚的特質。
  •     大部分時候,業務的變化都是流程的變化,並且都是和用戶打交道的的部分,也就是用戶訪問生命週期沒所以這一部分的變動最頻繁。
  •     業務對象是很穩定的,因爲分工的變化並不是經常發生,其內在邏輯是相對穩定的,值得依賴。
  •     組合實際上已經包含了面向過程和麪向對象的兩個特質,因爲組合要使用拆分的對象來完成過程的實現。

第二十二章 軟件架構與設計模式

  •     軟件設計模式本身是一個架構拆分的結果,只是這個才分被標準化了,所以被重複使用而已。而設計模式在被使用的時候,則不需要進行設計,直接使用即可。因此設計模式就成爲了一個成熟的技巧或者技術了。
  •     軟件設計模式這部分的代碼其實是有自己的業務領域的,這個領域就是軟件的訪問生命週期。
  •     畢竟模式知識關注到了共性,共性只會讓解決問題變得更容易、更輕鬆,因爲別人解決過了,有參考,但無法解決真正的問題。而真正要解決問題則是要發現問題的個性,發現了個性,共性才能發揮更大的作用。

第二十三章 軟件架構和軟件框架、

第二十四章 軟件運維

  •     因爲軟件本身也是軟件的業務。
  •     運維的業務目標是保證用戶的訪問生命週期不受影響。
  •     非核心生命週期的意思並非說該生命週期不重要,而是不再需要自己親自幹,可以分工出去給別人幹,用來提高並行度。
  •     每次變化的風險控制是最重要的任務。
  •     而爲了要控制變化,隔離環境是第一件要做的事情。
  •     環境隔離導致了架構的拆分,企業的環境隔離形成了一個架構拆分。
  •     監控的目的實際上就是把系統內不同生命週期的當前運行狀態,通過探測器傳輸過來,展示到可視或可感知的設備上,來供人查看。
  •     監控非常重要的指標就是實時度。
  •     不留戀過去,是大自然能夠得以不斷持續向去發展的前提。
  •     監控室生成預警的數據基礎。對業務生命週期的理解則是生成預警的規則基礎。
  •     預警軟件本身也是需要監控和預警的,也是預警的業務。
  •     在生產系統做變更,也需要有一個正向的反饋環,這個正向反饋環核心環節就是監控和預警。
  •     變更在生產環境的執行一般稱之爲發佈,對變更進行管理的系統佳作發佈系統。
  •     生產故障時要優先恢復用戶的正常訪問,而不是在生產環境探查問題的根本原因。

第二十五章 軟件訪問生命週期

  •     可以得出結論,訪問路徑上的業務,都是計算機和軟件自身的業務,是爲降低軟件的開發難度而沿着訪問生命週期做架構拆分而形成的。
  •     計算機和軟件的業務都可以歸結爲訪問通道型的業務。

第二十六章 軟件架構和大數據

第二十七章 軟件架構和建築架構

第二十八章 交易

  •     交易就是人各自拿自己多餘的物品,從其他人手上換取自己必須的物品,從而雙方都獲得利益的過程。
  •     交易的背後實際上是人們相互之間的時間交換,而不是貨幣。貨幣只是對時間的定價,方便交易的一個工具。
  •     對於不同的商業模式,交易都有自己的形態,需要識別出來。

第二十九上 產品

  •     產品本身就是最好的營銷。
  •     產品系統實際上就是市場營銷的起點,也是交易的起點,也是企業用來年實現自己願景的工具,是願景的具體化。

第三十章 用戶

第三十一張 訂單

  •     其實浮渣的事情一開始都是簡單的,簡單的系統逐漸地發生拆分就變得越來越複雜了。

第三十二章 交易系統

  •     業務模型完全就是現實社會中已存在的分工,建模的人只需要識別出來就可以,不需要絞盡腦汁用不同的技術抽象出來另外建立一個模型來表達業務。
  •     訪問通道的另一個非常重要的要求是,不同類型的用戶訪問要提供單獨的訪問通道。
  •     要讓各方都有自己的訪問通道,保證訪問通道不能夠重用。
  •     不重用訪問通達的目的是爲了重用業務對象。一旦重用訪問通道,業務對象中的業務邏輯一定會分散到訪問通道中,業務邏輯反而得不到重用了。
  •     一旦軟件發生了架構拆分,原來的本地調用就變成了服務調用。
  •     架構拆分導致了服務的出現,反過來,服務也是達到加厚拆分的必要技術手段。
  •     服務有自己獨立的生命週期,會形成自己獨立的業務,不再依賴於原核心生命週期,煥發出型的活力。

第三十三章 事務
 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章