在王概凱先生的9篇關於軟件架構師的博客-《架構漫談》中，我們可以看到文中談到了架構的定義、含義，架構主要是要認識概念，如何做好架構之架構的切分，然後談到了軟件與架構之間的關系（什麽是軟件，軟件架構是要解決什麽問題，從架構的角度看如何寫好代碼，理清技術、業務和架構之間的關系了），下面依次寫出我對9篇博客的理解與感悟，以及對軟件架構師工作的理解。

　　一：什麽是架構

　　　　在學習軟件體系結構這門課之前，我們貌似只對軟件開發以及簡單的mis系統的開發有一絲絲的開發經驗和感觸，無架構之言。我們目前還無法像軟件架構師那樣去思考問題。在第一篇博客中，王先生給出了架構的基本定義-Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton”architect”, from ?ρχι- “chief” and τ?κτων “builder”) is both the process and the product of planning, designing, and constructing buildings and other physical structures。（從這個定義上看，架構好像是一個過程，也不是很清晰。為了講清楚這個問題，我們先來看看為什麽會產生架構）。

　　 在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的（當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的）。一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的事情，並具備一定的交易能力即可。

　　當然，最後王概凱給出了架構的概念，即：根據要解決的問題，對目標系統的邊界進行界定。所以，一個合格的軟件架構師，需要以一種類似與結構設計是來看待問題、分析問題，提出問題的解決方案。

　　二：認識架構是理解架構的基礎

　　　　在“概念”這個含義中，很多人都有認識的誤區，下面，我就介紹一下文中作者給我們舉出的例子：大部分人對於每天都習以為常的概念，都自以為明白了，但實際上都是下意識的，並不是主動的認識。比如說“什麽是桌子？”，做培訓的時候，我經常拿這個例子來問大家，回答千奇百怪。這實際上就導致了做架構的時候，不同角色的溝通會出很多問題，那麽結果也就可想而知了。

　　　　如前一篇所說，架構實際上解決的是人的問題，而概念是人認識這個世界的基礎，自然概念的認識就非常的重要。這篇文章嘗試討論一下，如何去認識概念。當然這篇不是語言學的文章，我這裏所討論的，和語言學可能不太一樣，如果大家對語言學感興趣，也可以去參考一下。

　　　　文中，王先生提出了中國古代傳統文化關於“概念”的研究與探索。原文不在這裏贅述，大致意思是這樣的：在中國的古代，“概念”一詞的含義用另外一個詞來表示，即“名相”。相-即能看到的東西，當聽到完整的名詞，腦子裏想到的實物（包括他的形狀、用處等）叫做-名，加一起就是名相。但是，如果這個物體性狀發生改變，我們對它的感覺也會發生改變。比如說，一個杯子，打碎了，便是一堆碎瓦片。如果磨成粉，那就是一堆沒用的齏粉。那究竟什麽才是相？實際上“相“表達的不是一個具體的東西，如上面所提的一個瓷器杯子，並不是指這個瓷器，而是這個瓷器所起的一個作用：一手可握，敞口（一般不超過底的大小，太大口就叫碗了），並且內部有一個空間可乘東西的這麽一個作用。並不是指這個瓷器本身。這也是為什麽我們從電視上看到一個人拿杯子的時候，我們知道這個是杯子。但是實際上我們看到的都是光影而已。所以說相實際上代表的是這個作用，並不是具體的某個東西，而名是用來標識這個作用的，用來交流的。

　　　　回過頭來，根據架構的定義，要做好架構所首先必須具備的能力，就是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。事實上，這一能力，在任何一個領域都是適用的，比如我們如果想要學習一項新的技術，如Hibernate、Spring、PhotoShop、WWW、Internet等等，如果知道這些概念所要解決的問題，學習這些新的技術或者概念就會如虎添翼，快速的入手；學習一個新的領域，也會非常的快速有效；使用這些概念來解釋問題，甚至發明新的概念都是很容易的事。

　　三：如何做好架構之識別問題

　　　　按照之前架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麽問題就已經解決了80%了。這個能力基本上就決定了架構師的水平。可是，當我們面對問題是，有哪些困難呢？原文中的一則笑話，可以說明形象的表達困難在哪。女主人公：老公，把袋子裏的土豆切一半下鍋。結果老公是把袋子裏的每個土豆都削了一半，然後下鍋。被告知要處理一個問題，但是交過來的實際上是一個解決方案，不是問題本身。被告知要處理一個問題，直接通過直覺就有了一個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適。作為軟件工程師或者架構師，我們大部分時候是要去解決別人的問題，“別人”是誰，是值得好好思考的。在這個故事裏面，男主人要解決的，實際上是這個家庭晚餐需要吃土豆的問題，目標問題的主體實際上是這個家庭的成員。這裏，我們得到了一個結論，即軟件架構師應該考慮問題的本質，用戶真正需要的，而不是按照自己的解決方法，敷衍的解決問題，這裏好像是數學中的大題。如果有一道很復雜的函數問題，給人直觀的感覺是可以用各種式子推到出來。可這是出題人的原想法嗎？細心點我們可以發現，原來這道問題可以用一個定理推導得出。所以，解決問題，我們要學會找出提這個問題的人的真正需求，而不能簡單的按照自己的解決思路生搬硬套。

軟件架構師如何工作-架構漫談閱讀筆記