剛剛閱讀了《架構雜談》一到九，感覺收穫頗多，將自己的理解整理了下來。
架構漫談是由資深架構師王概凱Kevin執筆的系列專欄，專欄以Kevin的架構經驗為基礎，逐步討論什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程式等問題。在此向大家推薦這九篇博文，相信每個人都會有收穫。
什麼是架構？
在軟體行業，對於這個問題，一直存在很大的爭論，每個人都有自己的理解。沒有一個完整的定義。文中套用了一句關於big data流行的笑話來形容：Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。不得不承認，看完這句話我就笑了，但是仔細一想，話雖簡單，卻蘊含這深刻的含義。架構的英文是Architecture，在Wikipedia上，架構是這樣定義的：
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。
從這個定義上看，架構好像是一個過程，也不是很清晰。博文中對此有著詳細的闡述，把一個整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為一個整體，並完成這個整體所需要的所有活動，這就是架構。
認識概念
基礎概念對於做架構是非常重要的，大部分人對於每天都習以為常的概念，都自以為明白了，但實際上都是下意識的，並不是主動的認識。比如說“什麼是桌子？”大家回答千奇百怪。這實際上就導致了做架構的時候，不同角色的溝通會出很多問題，那麼結果也就可想而知了，文中討論了一下認識概念的誤區，如何有效的去認識概念，明白概念背後的含義，以及如何利用對概念的理解，快速的進行學習。掌握了這些原則，會有利於幫助我們在架構階段，快速的識別和定位問題。
按照上面架構的定義，做好架構首先需要做的就是識別出需要解決的問題。一般來說，如果把真正的問題找到，那麼問題就已經解決80%了。這個能力基本上就決定了架構師的水平。博文引用了一個笑話引出了我們在處理問題時犯的錯誤，1.被告知要處理一個問題，但是交過來的實際上是一個解決方案，不是問題本身；2.被告知要處理一個問題，直接通過直覺就有了一個解決方案，馬上考慮解決方案如何落地，或者有幾種解決方案，選哪個合適。要正確的認識問題，需要問兩個問題1. 這是誰的問題？2. 有什麼問題。
架構切分
切分就是利益的調整，當人們認識到要主動的去切分一個系統的時候，毫無疑問，我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點，這是大方向。。因為每個人的時間是有限的，怎麼在有限的時間內做出更多的事情？那麼只有把時間上連續的動作，切分成時間上可以並行的動作，在空間上橫向擴充套件。所以切分就要有幾個原則：
1.必須在連續時間內發生的一個活動，不能切分。2. 切分出來的部分的負責人，對這個部分的權利和義務必須是對等的。3. 切分出來的部分，不應該超出一個自然人的負載。4. 切分是內部活動，內部無任怎麼切，對整個系統的外部應該是透明的。
軟體架構的出現
軟體的本質，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產力，提升人類自己的利益。軟體工程師的職責在這個浪潮中，不堪重負，自然而然就分拆為不同的角色，形成了一個獨特的架構體系。這一切的背後，仍然是為了提升人類自己的利益，解決人類自己的問題。
當我們說軟體架構的時候，我們一定要講清楚，究竟說的是部署的架構，還是程式碼的架構。軟體架構的落地，需要軟體的組織架構和流程來保障，離開了這個，軟體架構是一句空話。
另外很多人講，架構是進化出來的。架構實際上是在量不斷的增大，超過了單臺伺服器的容量，逐漸的分拆，同時導致超過單個人員的能力，工作人員不斷的增多，工作內容不斷的分拆形成的。這本身就是架構的意義所在。不管怎麼分拆，所達到的目標沒有任何變化，就是完成業務在計算機中的虛擬化。
架構師
架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是一個leader。但是隻是民意上的leader是沒有用的，不能完全發揮架構師的能量。
架構師必須是一個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。所以很多公司設了很多架構師的職位，但是並不具備調動組織架構的權利，那麼這個架構師的職位一定是形同虛設。架構師只能夠通過建立某些流程來行使架構師的權利，比如強制架構review，反而會造成很多內部不必要的衝突，最終都會導致這些流程流於形式，得不償失。
我們真正想快速的完成程式碼工作，就要克服自己對時間的恐懼，真正的去研究業務的問題，相關stakeholder的利益，把這個變成我們的習慣。寫程式碼的時候讓該出現邏輯的地方出現邏輯，讓不該出現的地方不能出現。一旦不該出現的地方出現了邏輯，那麼要馬上意識到，這個地方是一個坑。
準確識別採用什麼技術的能力，也是架構師所要具備的能力之一。考慮的主要因素也是長期的成本和收益。