在網上（51cto裡）看到的資料轉至我個人的博定，給勉勵自己：
架構師成長之路：
（1）、 每乙個好架構師都是好程式設計師
江南白衣曾撰文述說：「國內的架構師到了三十歲以後很多就往理論上跑，而國外的架構師在往上發展的同時保持下面的程式設計體驗，所以國內多水王，而國外則多大師。」，優秀的編碼水平，是成為乙個架構師的基礎。
（2）、 抽象思維：駕馭概念的技能是最高潛力
（3）、技術前瞻性：站在技術的山頂向前眺望
有人談到技術高手與架構師的區別就在於，架構師不光是著眼於現在，不僅僅侷限於開發細節，比如如何呼叫，如何併發等等。而是跳出三界外，考慮一下面向未來問題和潛在風險的應對之道。
那程式設計師該如何培養自己的技術前瞻性呢？很大程度上來說還是要學好英語，國外的新東西，老東西的新特性肯定都是用英文寫的。即使國內有很多**也在做外電翻譯，但面對海量的資訊肯定是杯水車薪。而且有不少程式設計師所面對的領域本身關注度就不高，靠外部翻譯似乎很難實時跟進。這時就需要有良好的外語水平，能看懂國外的技術文章和文件，能與國外相關人士進行交流。
外功是從外部獲得最新技術資訊，那麼內功就是自己的邏輯思維能力和接受能力。再新的技術，其實也與以前的技術有結合。這也是為什麼我們說架構師首先是卓越的程式設計師，也就是這個道理。
（4）、問題解決大師：架構師修練課程-透過問題看本質
什麼是本質？將世界萬物理解為原子，將整個網際網路理解成0和1，這倒的確是非常本質了，不過並不能解答任何問題。從問題看本質，實質上是乙個從表層逐步深入的過程。在架構師面對乙個使用者需求時，這個「使用者需求」是非常表層的——比如說，乙個自動遠端備份資料庫的功能。而架構師的主要工作，就是把這樣的「業務需求」翻譯成「技術需求」。這個過程一方面需要通過抽象思維將使用者需求提煉為啟動、讀取、儲存、中斷處理等模組，而另一方面則需要看到更深層次的網路、作業系統、硬體等方面，以及其可靠性、穩定性、適用性、安全性等問題。
（5）、多領域知識：架構師-要成為百科全書式的智者
通常來說我們將架構師分為系統架構師、軟體架構師等等。雖然有分工不同，各自所處的層次也有不同，但是究其核心能力，跨領域知識的學習能力，是架構師的強項所在。
架構師身為一名技術領袖，需要通過發散知識的光芒來統御開發團隊的。如果只是對本行業知識做到爛熟於心，那還僅僅是一名熟練工的水平。要想晉公升更高的層次，還需要跳出「只緣身在此山中」的困惑。例如在目前國內架構師，至少有網路領域為依託，物流金融**等熟知越多越好，這個是應用級別。比如南天的金融平台研發部門，但是這個成不了底層平台架構師。再往上走，很多公司的研發人員不是精通計算機，可能是物理極為精通，比如中軟研發聲納軟體部門很多人對資料訊號極有研究。
談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽群書，加上高中之前各學科紮實的基礎，相信大多數程式設計師本身就具備一定的跨領域學習的能力。但想成為真正的百科全書式的智者，恐怕不光是簡單覺得眼熟就行。在條件允許的情況下，程式設計師其實可以去參加一些其他領域的專業考試。比如參加會計資格證的考試，抑或其他專業中較初級的考試。這樣的經歷，主要還是在於「以學促考」，通過一定的壓力讓自己能鑽進去學習。
（6）、溝通能力：架構師-善於溝通的技術領袖。
究竟怎樣才能是一名合格的架構師，成為一名真正能說會道的程式設計師呢？首先自然是溝通要清晰明了，平和待人。架構師不能將自己鎖在自己的象牙塔上，頤指氣使的對程式設計師發號施令。這樣的態度必然遭到程式設計師的憤恨，大家都是一樣的技術人員，只是分工的不同，為什麼要受氣呢？
（7）、內力：架構師要努力成為內功深厚的高手
講到內功深厚，大家心想「那我就往死裡鑽研技術，不就完了？」。確實，很多人理解的內力就是開發技術，包括語言的掌握、對框架的掌握、資料庫管理能力、安全管理能力等等。但是我們看到，架構更多的內力體現在對技術的綜合運用上，光會程式設計的程式設計師，最多就能做到高階程式設計師，也就是技術實現上的高手。
內功的修煉第一層，自然是開發技術的培養。從寫第一行**開始，就多想為什麼，有沒有什麼其他的路徑能實現同樣的功能。當我們寫了很長時間**了，是不是就該考慮更多的問題，比如優化、預期未來。其次是對架構的熟悉，下面是大家比較熟悉的struts 2架構圖。要做一名優秀的架構師，就得對各種架構做到了熟於心。
更高層次的修煉，就在於不同技術的學習。要懂得資料庫知識，懂得安全監控方面的知識，還要懂得網路構建方面的知識。這是比較高層次的內功修煉，很有可能與程式設計師目前所處的開發環境關係不大，對程式設計師來說並不是什麼有用的東西。但乙個優秀的架構師必須懂得這些，才能更好地抽象軟體的使用環境，選擇符合需要的架構以及開發模式。
（8）、權衡取捨：架構師-每天要在魚和熊掌之間做選擇
你聽說過軟體架構師的職業培訓中有乙個叫做atam的課程麼？atam，全稱architecture tradeoff analysis method，意為架構權衡分析方法。雖然這樣的培訓並非必要，但是值得我們去學習了解一下。
沒有乙個人可以建造乙個沒有缺陷的架構。這個專案可能缺乏時間，缺乏金錢，缺乏人手，或者缺乏合適的技術。在專案從開始到進行中的每時每刻，架構師都需要對這些架構的「缺陷」有明確的了解。
在架構師的藝術氣質篇我們提到了「基於需求考慮問題」和「基於系統考慮問題」的不同，並提到這中間會存在一些矛盾，需要架構師來做權衡決策。站在系統的角度上，架構師可能覺得自己手頭的資源不夠，他需要更多的時間、人以及新技術，但是專案經理和其他團隊成員很可能會拒絕，而他們也有自己的理由。
所以fred george先生提出了「短期濫用」的說法，即在系統能夠承受的範圍內做出一些妥協。在atam方法中，分析的思路是基於「情景」的：你需要提出各種可能的情景，然後來證明在每乙個使用者使用場景中，系統的哪一些內容是必要的、不可丟棄的——從而確定哪些部分是暫時可以不予考慮的。
作為一名優秀的架構師，比較迫切的管理任務可能就是開發成本與收益平衡的問題。舉例說，採用mysql做資料庫與採用oracle做資料庫，**肯定有很大差距。但是究竟該採用何種技術，架構師需要仔細權衡使用者的**與本公司收益率的問題。又比如說採取甲技術開發出的軟體，介面大方效能一般，但是需要耗費程式設計師更多的勞動時間，那在有些場景下就不如採用乙技術快速開發後節約的大量人力成本，儘管介面有些難看。
（9）、管控能力：架構師-要善於管理整個開發團隊
下面是泰勒的相關理論：工作定額原理、挑選頭等工人、標準化原理、計件工資制、勞資雙方的密切合作、建立專門計畫層、職能工長制、例外原則。仔細思考過後，這些東西有很多與現在的工作相似。就拿工作定額和挑選頭等工人來說，每位程式設計師的工作量都是訂好的，工資標準也是按照技術最好的「大拿」來做對比。至於人性化管理，滿足更高層次的需要，很多專案經理現在還考慮不到程式設計師的要求，專案經理就是泰勒理論中的職能工長而已。
作為一名優秀的架構師，比較迫切的管理任務可能就是開發成本與收益平衡的問題。舉例說，採用mysql做資料庫與採用oracle做資料庫，**肯定有很大差距。但是究竟該採用何種技術，架構師需要仔細權衡使用者的**與本公司收益率的問題。又比如說採取甲技術開發出的軟體，介面大方效能一般，但是需要耗費程式設計師更多的勞動時間，那在有些場景下就不如採用乙技術快速開發後節約的大量人力成本，儘管介面有些難看。
因此，架構師在管理和控制的能力上，需要有自己獨到的見解，而不是簡單的認為這是專案經理或者財務部門的事情。身為技術專家的架構師，隨不需要處理那些煩雜的日常管理。奇虎架構師李釗在一次接受採訪時道出過架構師們的心聲，技術人才轉向管理就是莫大的浪費。對，如果架構師只是一味的去進行專案管理，那就和其他市場人員沒有任何區別了。在這裡架構師所需要的管理與控制，其實是從技術的角度，對一些問題的控制，特別是開發過程中的監控，而不是普通意義上的純粹管理。
（10）、藝術氣質：優美的系統與架構師的藝術氣質
商業軟體專案的首要目標是實現來自客戶或公司的商業需求。然而，在架構過程中僅僅考慮到實現商業需求而建立的系統往往缺乏伸縮性、安全性、可維護性、可靠性、可移植性等等，導致其在短短數年內便因無法與時俱進而被拋棄。這一點幾乎每一位維護過專案的程式設計師應該都能夠體會到：面對著缺乏文件、不知所云的**，想要修改或新增乙個功能卻無從下手。
而乙個優美的系統則是可以像有機的生命一樣成長的，這是因為從系統開始架構的那一刻起，架構師就考慮到這個系統以後將會面臨的挑戰，為系統的成長預留好空間。專案經理經常會對這位架構師提出的看似理想化的要求不置可否——專案經理只想著能夠盡快以比較低的成本實現客戶的需求，然而這些充滿藝術美感的想法其實是打造健康——因而優美——的系統的根本因素。
檢視模型是業內在20世紀90年代開始逐步建立起來的一套規範（ieee 1471），不同的檢視從不同的角度對系統的不同方面進行關注。之前所提到的專案經理注重商業需求而架構師注重系統健康的矛盾，其實在這個檢視模型中都有相應的描述，為架構師開展思路提供了很好的指引。過去的十多年間出現了很多指引性的檢視以及框架，一些常見的 包括：
用例檢視（use-case view）：這是業務需求的角度。
邏輯檢視（logical view）：這是功能實現的角度，用例執行的流程圖。
上面兩個檢視是必需的，也往往是專案經理最關注的部分。如果只考慮這兩個角度，系統可以被建立，但正如之前所描述的那樣，是不可能優美的。架構師還需要視情況考 慮下面這些檢視：
程序檢視（process view）：如果系統是多執行緒的，高併發的，則需要考慮執行緒的角度。
部署檢視（deployment view）：如果系統分布在多節點，則需要考慮伺服器端和客戶端節點等硬體對映的角度。
資料檢視（data view）：如果持久層在系統中很重要，則需要考慮資料的角度。
架構師之路（七）架構師之路再思考
孫子曰 將弱不嚴，教道不明，吏卒無常，陳兵縱橫，曰亂。今天參加架構師之路沈劍老師的直播，根據他個人的經驗也再次引發我對架構師之路的再思考以及自我重新審視。其次，對於我們的中颱建設，我們的架構師確實要解決實際業務問題的，而不是炫技，在過程裡，架構師需要對當前的業務有個比較全面的認識，對技術本身也要有個...
架構師成長之路 4 架構師知識體系（方法）
哲學家常思考的問題 我是誰？我從 來？要到 去？不只是哲學家，我想每個人都有自己對這三個問題的認知。如果我們要成為架構師，我們自己要面臨的三大問題 找準自己定位 我是誰？在 怎樣做好架構師 我要做什麼？如何搭建架構師知識體系 我該怎麼做？這裡面就是做事方 目標 我要做什麼 方法 計畫 我該怎麼做 執...
架構師成長之路 4 架構師知識體系（方法）
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！前言 哲學家常思考的問題 我是誰？我從 來？要到 去？不只是哲學家，我想每個人都有自己對這三個問題的認知。如果我們要成為架構師，我們自己要面臨的三大問題 找準自己定位 我是誰？在 怎樣做好架構師 我要做什麼？如何搭建架構師知識體系 我該怎麼做？這裡...