從程序員到架構師的方法與邏輯

架構師這個詞常常見到，不少人都冠着這個頭銜，實際上不少人對架構師到底是幹什麼的都沒有統一的認識。V衆投發起人李智勇則利用特定場景進行分析，詮釋了架構師這個概念，並給出如何成爲架構師方法。

架構師是什麼？

架構師這詞其實頗有意思，不少人的Title是這個，但其實咱們對架構師都幹什麼並無太統一的認識。往大了說，比爾蓋茨當年好像也稱本身爲架構師，往小了說隨便一個小的軟件上作設計的也說本身是架構師。因此若是把這個詞泛化而不侷限於特定的場景，估計單是說清楚什麼是架構師就要花費很多口水。下面咱們用一個取巧的辦法，在一個具體的場景下來看看，架構師都該幹什麼，而不把這個詞泛化，若是在特定場景下這個角色應該幹什麼清楚了，那它就能夠爲其它場景下提供不錯的參考。

咱們只考慮從頭開發一款產品的場景，不考慮這款產品多是個家族，可能須要在公司裏與許多東西配合這樣繁瑣的事情。這樣問題就簡化成：當咱們要開發一款新產品的時候，架構師都要幹些什麼？爲讓事情更具體，咱們進一步假設公司想作一個Trello，Worktile這樣的協同辦公工具。

在產品初期除了UI這類東西，還能明確的一些關鍵需求大概是這樣：

• 簡單、迅速，追求極致的用戶體驗，這時也許能想到看板這樣的功能
• 打入社交元素（任務分配與溝通時打入信息流的機制）
• 移動端支持
• 公司判斷：若是產品能在1年內上線，時機比較好

其餘的需求呢就是感受上確定有，但暫時說不清楚

基於這樣的簡單提示，長作程序的可能腦子裏會馬上冒出來無數東西，好比：

• 快的確保?
• 看板裏拖動的實現？
• SaaS時伸縮性的確保？
• 數據庫中表的設計？
• 數據庫類型的選擇？
• 移動端的支持方式？
• 人員的現狀？
• 迭代式開發的支持？
• ... ...

但顯然不是每一個事情都要在架構設計階段搞定，不然等因而被弄蒙了，這時候架構師的一個關鍵職責就是要能區分出哪些東西預先須要搞定，而哪些東西則要在迭代過程當中解決。

通常來說重置成本越大，牽涉的人越多的事情越應該由架構師預先搞定，不然就容易作無用功，對開發工做產生致命傷害。具體來說這類事情由三個核心部分組成：

• 選定Tech Stack
• 概要設計，確立分工的基礎
• 協同方式

下面來分別解釋下這三個方面的具體含義。

選定Tech Stack是指要選定包括編程語言，基本框架等一系列東西，好比Trello選完以後大體是下面這個樣子：

圖片來自網絡

這事情幾乎是不可重置的，由於重置成本已經到了正常團隊不可能負擔的地步。因此Tech Stack與待開發產品的吻合程度是很是體現架構師價值的地方。選了Tech Stack但發現沒法達成產品目標是架構設計上最差的結果，也正由於輸不起，在這個環節上能夠慎重些。這種Tech Stack的選擇受限於上述所說的關鍵需求，好比快，支持移動端等。也就是常說的從需求的模型想技術模型的映射。在此我向你們推薦一個架構學習交流羣。交流學習羣號：948368769裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

瞭解些技術的應該一眼能夠看出來上面這張圖是MEAN（MongoDB，Express，AngularJS。。。，NodeJS）架構，這架構知足上面關鍵需求是沒問題的，但若是關鍵需求裏有一條叫以靈活的插件結構來知足不一樣用戶的定製化需求，上面這架構可能就有點麻煩了。

無論怎麼樣Tech Stack架構師第一個須要搞定的事情，沒這個什麼活也幹不了。

再其次則是相對比較傳統一點的部分，無論從哪裏開始迭代，老是要切分前端後端的職責，設計彼此交互的接口，要區分出來哪些是純工具型的模塊（好比日誌），哪些是基礎設施型的（好比用戶管理與權限），哪些是能夠完全進行迭代的（好比具體的某個功能）。這些東西之間是有一種內在的時序關聯的，不是簡單一句：咱們迭代吧，咱們測試驅動開發吧，就能夠的，那會致使很大的混亂，因此這裏也是架構師要扮演角色的地方。傳統上管這個叫概要設計，雖然這詞如今不怎麼用了，但這詞其實還不錯的。固然架構師不必定要一我的搞定全部這些事情，而是要肩負起協調你們搞定這些事情的職責。這個地方依賴於產品的類型對業務知識的要求程度不一樣：通常來說越是面向我的的產品，在業務知識上要求越低；越是面向企業的產品業務知識的要求越高。簡單講作天氣應用的時候可能直接作就好了，但作財務應用時瞭解財務的某些知識就挺必須的。

最後一項則是分工後的一種協做的方法，這裏麪包含着分支策略，持續集成策略等。

顯然的，下面兩種分支策略下，團隊的協做方式不同.。

圖片來自網絡

這是又一個全局性的工做，幹活前須要預先定下來應該也是沒疑問的，可是不是架構師搞定這事上，不一樣人的認知可能會不同，有的人會認爲應該是項目經理類的角色來搞定這事情。我我的則堅持認爲理想情形下應該架構師搞定這事，由於分支策略等受技術的約束更大。

這就是我理解中架構師的要乾的三類活：選擇Tech Stack，概要設計來確立分工的基礎，確立協同的方式。

在開發產品時，這三樣事情不搞定，迭代都很差迭代。抽象點來看是這樣：假設說在現有人員的基礎上，預先搞定某問題須要耗費的成本爲X，而迭代後，事到臨頭再處理，其耗費的成本爲Y，那麼無疑的Y>X的問題都應該是儘量預先處理的問題，而不能以迭代爲藉口冠冕堂皇的進行忽視。而上述三方面問題，基本上是Y>X這類。

如何成爲架構師？

首先想說的是程序員不必定要成爲架構師的，優秀的程序員同樣頗有價值，但關鍵要看技術領域，我在程序員能夠只關心技術麼？ 專門說過這事，這裏再也不展開。

真要想成爲架構師事實上老是有兩類方法，這兩類方法倒不侷限於架構師的學習，而是普適於任何學習。

一種是從概念規則到實踐，一種則是從實踐總結出概念和規則。數學更近似前者，而歷史更近似後者。當咱們試圖先抽象出什麼是架構設計，架構設計又有那些原則，以後再讓你們瞭解現實中的架構設計如何作時，無疑的採起的也是前者的方式，也就是數學的方式。這種方式在現實中比較常見，但在邏輯上是有問題的：正是由於對架構設計的不理解，才嘗試學習架構設計，即如此想學習的人天生在瞭解架構設計的概念與原則會遭遇困難。在此我向你們推薦一個架構學習交流羣。交流學習羣號：948368769裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

出於這樣一種考慮，最好的辦法實際上是先了解一些最基本概念，好比前面說的那些，再瞭解一些最基本的原則，好比：正交，信息隱藏等。以後就不在抽象概念層面打轉了。而瞭解多個現有典型產品的架構，好比上面說的Trello，WordPress等。這時候最好對產品歸類，在特定類別下抽象出來一些典型的架構模式。好比：軟硬一體產品的架構，CMS的架構等。這樣一來，若是一我的能夠主要學習其中之一，順道瞭解其他，那就能夠比較迅速的掌握架構設計的知識，至少是上面說的架構設計中的前兩類知識：Tech Stack的選擇與概要設計。在開源的時代裏，這已經成爲一我的坐在家裏就能夠完成的事情了。

一點呼籲

最後作一點呼籲。如今各類架構設計的課程仍是比較多的，但基本上都是按照第一條思路來的，好比：講架構設計時會去嘗試把架構設計分解爲邏輯架構，運行架構等。從身邊人的效果來看，廣泛不太理想。有實力的培訓機構能夠嘗試總結架構的模式，以一個總綱帶領幾個典型領域的架構分析，好比：CMS就參照WordPress來說架構，基礎JavaScript庫就參照Backbone這種等。也不用太多，覆蓋典型的4~5個領域就能夠解決很大的問題了。這應該會更有效果，但課程建立上會比較吃力些，真想作的人要有思想準備。我我的曾經嘗試和南京的TalenCamp按照第二條路來設計課程，但因爲各類緣由暫時進展不太大。