時光退回到七八年以前，那個時候“架構師“還是一個很“高大上“的title?？墒窃诮裉斓幕ヂ?lián)網(wǎng)圈，隨便一個工作了三、五年的開發(fā)人員，都可以稱之為架構師。
隨便多翻幾個招聘網(wǎng)站，你可以看到：前端架構師、后端架構師、Android架構師、iOS架構師、PHP架構師、運維架構師、DB架構師、搜索架構師、中間件架構師、大數(shù)據(jù)架構師。。。五花八門，不一而足。
從這些崗位需求可以看出，“架構師“這個詞其實是一個很“虛“的詞，不同技術領域、不同行業(yè)，所要求的技能點、所側重的能力模型是差別很大的，不是一個簡單的“架構師“就可以概括的。
而本文也將談談我個人對“架構師“這個職位的理解：雖然不同領域要求的能力模型不一樣，但個人認為，作為一個“架構師“，還是有一些共同的東西需要掌握的。
“格局“這個詞聽起來比較虛，但我舉個通俗的例子：你去一個陌生的城市旅游，我想你首先需要的就是一張“地圖“。這張地圖定義了這個城市的“邊界“，也定義了這個城市的所有地方，通過這張地圖，你會對這個城市有一個“全局的了解“。
而這種“全局的視野“，不是說架構師才需要，換做其他職位、其他行業(yè)，同樣的道理。做產(chǎn)品經(jīng)理，需要對產(chǎn)品有“全局視野“；做運營，做市場，需要運營、市場相對應的全局視野；做技術，需要技術相關的全局視野。
說了這么多，可能還是比較“虛“，我就舉個例子來說明到底什么叫“全局視野“，比如你現(xiàn)在負責開發(fā)一個新系統(tǒng)，你可能需要去理解下面這些關系到“大局的問題“：
這個系統(tǒng)的定位是什么？它能創(chuàng)造什么核心價值？
做這個系統(tǒng)的背景是什么？－－ 為什么以前不做，現(xiàn)在要上？是因為業(yè)務發(fā)展到了一定規(guī)模？還是開發(fā)資源現(xiàn)在有多余，沒事可干？
這個系統(tǒng)在整個組織架構中，處于什么位置？跟這個系統(tǒng)關聯(lián)的其它系統(tǒng)目前什么狀況？
產(chǎn)品經(jīng)理如何看待這個系統(tǒng)？技術老大如何看？
這個系統(tǒng)的需求，是處于比較確定、比較清晰狀態(tài)？還是有很大灰度空間？很多核心點，大家還沒想清楚？
這個系統(tǒng)所用的技術體系，是比較老？還是最新的？
業(yè)界類似的系統(tǒng)，人家是如何做的？
。。。
關鍵點：上面隨便舉的這個例子，并沒有標準答案，我想表達的是，一個有“大局觀“，一個有“格局“的人，在做一件事情之前，要對所做的事情有一個“全局把握“，風險在哪？挑戰(zhàn)在哪？提前要有心理準備！
最后再多說一句：“格局“是有層次的，國家總理在“國家“這個層次思考，CEO在行業(yè)、“公司“這個層次思考，業(yè)務線負責人在他所負責的那個“業(yè)務“層面思考，技術老大可能主要在“技術層面“思考，產(chǎn)品老大在“產(chǎn)品層面“，到了最下面，寫代碼的，在“代碼“這個層面思考。
不同層次的人，聚焦的范圍大小不一樣?？扇绻隳馨涯愕摹胺秶巴鈹U一圈，這對你做自己的“本職工作“會很有好處。
而這，在我看來就是“格局“。
如果說“格局“是從空間的角度去看待問題，那么“歷史觀“就是從時間的角度去看。
任何一種技術，都不是誰吃飽了沒事干憑空想象出來的，它一定是要解決某個特定問題。而這個特定問題，一定有它的歷史背景：是因為之前的技術，在解決這個特定問題上，解決的不夠好、或者有其它副作用，所以才發(fā)明了這個新技術。
所以，看待一個技術，一個方法論，需要把它放到“歷史長河“中，去看它在歷史中，處于什么位置。
推而廣之，何止是技術，任何其他學問，何嘗不需要“歷史觀“？說個更專業(yè)點的哲學名詞，就這是所謂的“歷史唯物主義“吧！
同“格局“一樣，“抽象能力“又是一個很“虛“的詞?？勺鳛榧軜嫀煟褪切枰@種“務虛思維“。
抽象也是一個“層次“結構，從最底層到最上層，不同工作階段，你需要在不同抽象層級進行思考。
很多寫代碼的人，都比較習慣“自底向上“的思維方式。當你跟他討論需求的時候，他首先想的是這個需求如何實現(xiàn)，而不是這個需求本身是否合理？這個需求跟其它需求有什么關聯(lián)關系？
這種過早考慮“實現(xiàn)細節(jié)“的思考方式，會讓你“只見樹木，不見森林“，最終淹沒在茫茫的各種細節(jié)之中，層次混亂，把握不住重點。
同樣拿上面的例子舉例，假如讓你做一個新的系統(tǒng)，那么從“抽象“到“細節(jié)“，你可能需要考慮：
每個需求的合理性？
這個系統(tǒng)的領域模型是什么樣的？
這個系統(tǒng)是應該在舊的上面改造？還是應該另起爐灶？
這個系統(tǒng)可以分成幾期，分期實施？
這個系統(tǒng)要拆分成幾個子系統(tǒng)？
每個子系統(tǒng)又拆分出多少個模塊？
系統(tǒng)的表設計？api接口設計？job的設計？系統(tǒng)之間的消息傳輸？
。。。
從上到下，是一個逐級細化的過程，并且進入到下1級之后，上1級可能又會退回去修改。
深入思考能力，這里主要指“技術“的深度。關于“廣度“，在上面的“格局“這個層面已經(jīng)包含。
“深度“不是說，你要在所有領域都很深。人一生的精力是有限的，你不可能對所有技術領域都很深，但你需要1個比較深的領域。
這種深度，并不代表你當前的工作就需要這個技術領域，而是說這種“深入思考的方式“，會讓你在思考其他問題時，也會帶著這個“習慣“。
這個東西很重要，因為技術一直在更新?lián)Q代，當你面對一個新技術的時候，如果你有深入思考的能力和習慣，那你對新技術的理解往往也就很透徹。
同時，“深度“會讓你對“技術風險“有更加清醒的認知，你做一個項目的時候，這里面潛在的“坑“，你可能會提前發(fā)現(xiàn)，而不是等做到那了，發(fā)現(xiàn)問題了，被迫思考。
任何的架構必須可以落地，可以實現(xiàn)。不能落地，只能停留在ppt上面的架構，那只能忽悠人。這種架構，對實際不僅沒有指導作用，還會有反作用，對實際開發(fā)產(chǎn)生誤導。
而一個架構師，應該跟蹤從架構設計到架構落地到完整過程，“理論“到“實際“必然是有間隙的，跟蹤這個過程，實時修正，才可能真的做到“理論“與“實際“的統(tǒng)一。
業(yè)務架構和技術架構通常是2個不同的側重領域，業(yè)務架構強調的是對“領域“的深刻理解，這通常和“領域專家“密切相關，這里可能會強調系統(tǒng)的“可擴展性“，“可復用性“，對需求的彈性應對；
技術架構，需要對底層技術有足夠的把控，這里可能會強調系統(tǒng)的“高性能“，“高并發(fā)“，“高可靠“等。
業(yè)務架構和技術架構并不是相互獨立的，一般都是“業(yè)務驅動技術“，2者在互相促進中，同時往深度、廣度上發(fā)展。
再復雜的系統(tǒng)，都是“人“開發(fā)出來的。而人多了之后，“人“相關的問題都會自然產(chǎn)生：溝通不充分、組織混亂、職責不清。。。
作為一個架構師，一般很難“獨善其身“，說我只管“技術“，不管“人“。因為你的工作，是一個“團隊“完成的，而不是一個“千里走單騎“的英雄。
所以熟悉整個組織架構，瀝青職責，把各種混亂的流程、協(xié)作理順，也是應該考慮在內的。
說到現(xiàn)在，你會發(fā)現(xiàn)，我可能說的并不是一個“純粹的架構師“。的確如此，上面這些是我認為作為一個“技術人“，應該去不斷修煉的東西，而不是光“架構師“需要。
