本學期的新課程軟體體系結構，之前的編碼經驗對於軟體體系結構的概念十分模糊。一是之前的專案體系太小，邏輯簡單，對於體系結構沒有太大的要求。二是對於軟體體系沒有基本的了解，好像也只有之前學的設計模式與軟體體系結構沾點關係。在閱讀了架構漫談後，算是有了一些基本的了解。
首先什麼是架構，文章的原話是「把乙個整體（完**類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為乙個整體，並完成這個整體所需要的所有活動，這就是架構」。由於每個人的能力有限，且專案複雜不能由單人完成，所以要考慮分工並建立溝通機制以提高工作效率。架構實際上就是指人們根據自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，並進行分解、合併，解決這個問題的實踐活動。架構的產出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合併的原則以及理由，以及拆分，拆分出來的各個部分和合併所對應的角色和所需要的核心能力等。
每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了乙個名字，這個名字就是對應的某個特定的概念。「架構」也是是同樣的乙個特定概念。架構師要解決的，基本都是別人的問題，不是自己的問題，任何找上架構師的問題，絕對都不是真正的問題。因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。
了解軟體體系結構要了解什麼是軟體。軟體其實是模擬人和社會，把我們乃至社會向虛擬化到計算機中，比如模擬大氣運動（天氣預報），模擬人類社會（網際網路社交），模擬交易，包括現在正在流行的 vr，人工智慧等等。模擬的物件越來越高階，難度越來越大。所以說軟體的於目的是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟體主要依賴的還是人類的生活知識。
軟體架構的出現，由於軟體的複雜性，需要大量的計算機語言的知識以及相關領域的專業知識，這遠遠超出了個人的能力。所以軟體開發就開始有分工了，行業知識和業務的識別，會交給ba，系統的設計會交給架構師，設計的實現交給架構師，實現的檢驗交給測試，還有很多其他角色的配合。為了組織這些角色的工作，還有專案經理。這就把原來乙個人的連續工作，拆分成了不同角色的人的連續配合，演化成了不同的軟體開發的模式。然後慢慢演變出專門為別人開發軟體的軟體公司。
什麼是架構師，架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是乙個 leader。但是只是民意上的 leader 是沒有用的，不能完全發揮架構師的能量。架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。
技術，業務與架構的關係。技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求–也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？ 沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。
架構漫談讀後感
應老師的推薦閱讀了由資深架構師王概凱 kevin 執筆的系列專欄 架構漫談 9篇文章遞進地講述了 討論什麼是架構 怎樣做好架構 軟體架構如何落地 如何寫好程式等問題，文章生動形象多次舉通俗的例子讓本來生澀的知識變得更加容易理解，感觸頗多。對這系列文章印象的較深的一點是 一直在挖掘一些本質的東西，對一...
架構漫談讀後感
花了一周的時間利用課餘的閒散時間，總算看完了王概凱的架構漫談，這九篇部落格從相對全面的角度對架構進行了概述。自己也對架構有了更深一層的認識。感覺作者在部落格裡提到的對架構的理解對我們初學者來講幫助其實很大。架構其實就是根據要解決的問題，對目標系統的邊界進行界定，然後對目標系統按某個原則進行切分，接著...
架構漫談讀後感
這學期新開設了軟體體系架構這門課，學這門課之前架構漫談的九篇部落格進行了閱讀，對這門課以及架構設計進行了初步的認識與了解。通過對這幾篇部落格的閱讀，首先需要明白什麼是架構，在最早期，每個人有自己的生活方式，人與人之間相互獨立，不相往來，隨著慢慢的發展，男女共同生活，也就出現了各自的分工，有的人做這個...