今天將《架構漫談》又讀了一遍，在此進行了總結：
第一篇主要在介紹了什麼是架構以及為什麼會產生架構。文章中提到，架構是把乙個整體切分成不同的部分，由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為乙個整體，並完成這個整體所需要的所有活動。比如平時像我們學習中有很多情況下是在分工合作，與同學組成的團隊一起做專案，想要合理的分工，並最終將軟體做好，就需要做好架構，將整個系統功能分解，識別問題，拆分出來的各個部分和合併所對應的角色和所需要的核心能力等去有目的，主動的識別問題，並進行分解，合併，結果這個問題。每個人負責各自相應的模組，將自己的模組完成好。
第二篇主要介紹了架構的基本概念。概念很重要，如果沒有辦法理清一些基礎概念，混淆，會導致實際做架構時，角色溝通，工作安排會出現很多問題，自然工作結果也就不會樂觀。每個概念實際上解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了乙個名字，這個名字就是對應的某個特定的概念。不管是處於乙個怎樣的身份和地位，想要做好架構，就必須要正確的認識概念，能夠發現概念背後所代表的問題，，進而才能認識目標領域所需解決的問題。在這個問題上我需要努力的還有太多！
第三篇在講如何做好架構之識別問題，王概凱老師認為能夠識別出需要解決的問題，問題就已經解決了80%了，這個能力基本決定了架構師的水平。而識別問題的一大前提就是要搞清楚是誰的問題，這個搞清楚了，問題的邊界也就確定了，再去討論問題才有意義。乙個合格的架構師應該問的第乙個正確的問題是：目標問題是誰的問題。如果我們發現在工程專案中，正在致力於完成自己的工作，要馬上警惕起來，因為這樣下去會演變成沒有ownership的工作態度，在面對概念的時候，也會不求甚解，最終導致沒有理解正確概念。總之總結在正確認識問題的角度上，需要問兩個問題，是誰的問rr『』題，有什麼問題。讀到這裡我開始有些不明白，這是誰的問題，在我現在看來很難判定，比如談到切土豆這個問題，想要一把錘子這個問題，就反覆理解很多次，也還只是模稜兩可。
第四篇主要講是如何做好架構之架構切分。維護自己的利益每個人不能逃避的一點，隨著社會的發展，分工是必然的，每個人都想將自己的利益最大化，所以需要分工，用自己擅長的東西去換取別人擅長的東西。如果需要在這個社會上立足，判斷標準就變成了如何給這個社會提供更好更有質量的服務，提供更多更好的服務，自然就能夠換取更多更好的生活必需品，和我們做人的道理是一樣的。我們要捨棄自己的一些東西，去和別人交換，如果不想依賴別人，不願與別人交換，他就會辛苦很多，生活會差的多。
第五篇主要是將什麼是軟體。軟體的歷史，實際上可以說是用機械人模擬人的歷史，我們在有意無意的在計算機上模仿人類的行為，從馮諾依曼結構開始，程式邏輯開始脫離硬體，採用二進位制編碼。加上儲存。軟體開發就開始有分工了，行業知識和業務的識別，會交給ba，系統的設計會交給架構師，設計的實現交給架構師，實現的檢驗交給測試，還有很多其他角色的配合，為了組織這些角色的工作，還有專案驚雷，這就把原來乙個人的連續工作，拆分成了不用角色人的連續配合，演化成了不同的軟體開發的模式，然後慢慢演變成專門為別人開發軟體的的軟體公司。軟體架構的出現也是同樣的。一開始是懵懵懂懂的去寫軟體，後來就慢慢有意識的去拆分，演變成了不同的架構，這個背後的動力也是一樣的，就是提公升參與的人的利益，降低成本。導火索也是軟體工程師的任務太重，我們需要把很多任務作拆分出來。拆分的原則也是一樣的，如何讓權責一致，這個拆分也需要架構對的調整，來保證架構的落地。
第七篇講了怎樣成為架構師的前提條件，如何發現是誰的問題，架構師的權利和義務話題。架構師必須是乙個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。架構師要去平衡別人的利益，甚至會調整別人的利益，一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是乙個leader。但是只是民意上的leader是沒有用的，不能完全發揮架構師的能量。
架構漫談的第八篇講了從架構的角度看如何寫好**，當我們有了好的架構，那就需要考慮如何將架構落地，而這個時候，**就顯得無比重要了，千萬不要讓**成為架構擴充套件的瓶頸。軟體架構實際上包括了**架構，以及承載**執行的硬體部署架構，實際上，硬體部署架構最終還是由**的架構來決定，因為**架構不合理，是無法把乙個執行單元分拆出多個來的。
第九篇講了理清技術、業務、架構的關係，技術總是在人類解決對業務要求不斷提高的情況下產生，目的也是為了獲取更大的利益。業務是技術的前提，技術與技術有相互制約的關係，按照前面的架構定義，這個時候其實已經產生了架構，一般先有技術，才會有架構。
架構漫談 閱讀筆記（三）
作者 了軟體發展火熱的根本原因以及軟體扮演的角色等問題。就像說中所提到的我們並不缺架構實踐，而是缺少對於架構的反思。軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家 包括在這個歷史過程中的參與者 有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。從馮諾依曼結構開始，程式邏輯開始脫離硬體，...
架構漫談閱讀筆記三
在識別出問題後，大部分問題都會迎刃而解，但還是會有一些問題需要做出相應的調整，也就是架構的切分。切分是乙個很生動的詞彙 切分團體中每個人應得的 蛋糕 也就是合理分配每個人的利益。利益是乙個人生存的根本，所有維護利益是每個人的本能，人不為己天誅地滅 正是由此而來。有捨才有所得，在這個模式下，每個人都必...
閱讀筆記之 《架構漫談》三
我們要認識到，架構實際上解決的是人的問題。我們人需要什麼，應該用什麼東西來滿足我們的需要，通常不只有乙個東西能解決我們的需求，也不只有乙個需求用到同乙個東西，根據我們需求的不同，相同的東西可能會有不同的用法。我們必須要有這樣乙個概念，就是我們是為了在解決乙個具體的問題的前提下，才需要能解決我們問題的...