一、什麼是架構
在這一篇關於什麼是架構的文章中，作者通過類別的方式確實讓自己知道了什麼是架構，讓我心中對架構有了自己心中的理解。
在還沒有開始上「軟體體系架構」這門課的時候，老師在上課的時候就常常提到架構的重要性，已經架構一直都在我們軟體開發行業的最頂層，在這篇關於什麼是架構的文章中，我才發現，確實，在軟體開發之前，架構就已經存在於人們的生活中。
在架構產生的敘述中，指明架構產生的動力就是，必須由人執行的工作、每個人的能力有限、每個人的時間有限、人對目標系統有更高的要求、目標系統的複雜性使得單個人完成這個系統；這五個架構產生的動力方面讓我覺得都是必要存在的，模擬到我們軟體開發的過程中，首先，要有人執行工作，開發人員寫程式，需求人員做需求，其次，大家的能力和時間都有限，開發人員和需求人員這樣不同的分工就正好證明了這一點。乙個系統的開發，肯定離不開需求，需求從**來呢，就是來自於人對目標系統更高的要求。
1. 根據要解決的問題，對目標系統的邊界進行界定。
2. 並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。
3. 並對這些切分出來的部分，設立溝通機制。
4. 根據 3，使得這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成目標系統的所有工作。
二、認識概念是理解架構的基礎
本部分一開篇就提到：架構實際上解決的是人的問題，而概念是人認識這個世界的基礎。這兩句話就辯證的看待了概念和架構的關係，只有自己本身存在乙個概念，才能認識世界，進而理解什麼是解決人的問題，什麼是架構。
文章提到了「相」，這個我以為只存在於佛家倫理中的詞彙，感覺有點難懂，其實每個人都會有，是存在於每個人腦子潛意識中的東西，乙個概念，用來對特定的意見事情進行解決的概念，確實是很抽象。而後關於概念於架構的闡述，確實重新整理了我一些觀念。
根據架構的定義，要做好架構所首先必須具備的能力，就是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。事實上，這一能力，在任何乙個領域都是適用的，比如我們如果想要學習一項新的技術，如果知道這些概念所要解決的問題，學習這些新的技術或者概念就會如虎添翼，快速的入手；學習乙個新的領域，也會非常的快速有效；使用這些概念來解釋問題，甚至發明新的概念都是很容易的事。為什麼強調這個呢，因為做架構的時候，很多時候都是在乙個新的領域解決問題，必須要快速進入並掌握這個領域，然後才能夠正確的解決問題。
三、如何做好架構的識別問題
這部分開頭的笑話，說實話我實在是不能理解笑話中「老公」的做法，這也許就是兩個人思維的不同，也正好的指出了我們處理問題時會犯的一些錯誤，也引出了我們要如何識別問題。
首先就是「主語」確定的問題，所有的概念基本都有乙個很大的問題，就是缺乏主語。而我們大家都心照不宣的忽略這個主語，溝通的時候也都以為大家都懂得對方說的主語是誰，結果大家都一起犯錯誤。識別問題的乙個最大的前提就是要搞清楚：是誰的問題。這個搞清楚了，問題的邊界也就跟著確定了，再去討論問題才有意義。
作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，「別人」是誰，是值得好好思考的。當明白了問題的主體，我們才可能真正的認識問題是什麼。因為問題的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。
閱讀筆記架構漫談01
正如 架構漫談 作者所說，架構師必須是乙個組織的領導人。軟體架構師的主要任務並不是從事具體程式的編寫，而是從事更高層次的開發架構工作，因此軟體架構師需要有良好的組織管理能力以及一定的實權。要想成為一名合格的軟體架構師，首先要明白架構師是去幫助別人解決問題，而不是自己完成工作，並且工作完成與否是別人說...
架構漫談閱讀筆記01
產品所帶來的價值和出現的責任都是人為的結果。人對擴充套件性具有重要作用。如果想要確保產品可以擴充套件，人是最為重要的因素。在擴充套件性方面，忽略人的因素作用是錯誤的，這有可能是產品無法滿足使用者需求的根本原因。既然人是可擴充套件性的核心因素，我們就應花大力氣去吸引和留住最好的人才。不僅僅是要找到技能...
架構漫談閱讀筆記01
許多人都想成為架構師，我也不例外。這就不得不了解一下 架構 是什麼，想要知道 架構 是什麼，這就又不得不了解一下 架構 的起源。架構這個詞出現比軟體出現的早多了，或者說比計算機比資訊科技早多了，我想這就足以說明，所謂 架構 不是一種技術，不是好多大佬提到的應用架構 硬體架構 資料架構等等的具體技術，...