架構師是什麼？
架構師這詞其實很有意思，很多人的Title是這個，但其實我們對架構師都幹什麼並沒有太統一的認識。往大了說，比爾蓋茲當年好像也稱自己為架構師，往小了說隨便一個小的軟體上做設計的也說自己是架構師。所以如果把這個詞泛化而不侷限於特定的場景，估計單是說清楚什麼是架構師就要花費不少口水。下面我們用一個取巧的辦法，在一個具體的場景下來看看，架構師都該幹什麼，而不把這個詞泛化，如果在特定場景下這個角色應該幹什麼清楚了，那它就可以為其它場景下提供不錯的參考。
我們只考慮從頭開發一款產品的場景，不考慮這款產品可能是個家族，可能需要在公司裡與許多東西配合這樣繁瑣的事情。這樣問題就簡化成：當我們要開發一款新產品的時候，架構師都要幹些什麼？為讓事情更具體，我們進一步假設公司想做一個Trello，Worktile這樣的協同辦公工具。
在產品初期除了UI這類東西，還能明確的一些關鍵需求大概是這樣：
- 簡單、迅速，追求極致的使用者體驗，這時也許能想到看板這樣的功能
- 打入社交元素（任務分配與溝通時打入資訊流的機制）
- 移動端支援
- 公司判斷：如果產品能在1年內上線，時機比較好
基於這樣的簡單提示，長做程式的可能腦子裡會立刻冒出來無數東西，比如：
- 快的確保?
- 看板裡拖動的實現？
- SaaS時伸縮性的確保？
- 資料庫中表的設計？
- 資料庫型別的選擇？
- 移動端的支援方式？
- 人員的現狀？
- 迭代式開發的支援？
- ... ...
一般來講重置成本越大，牽涉的人越多的事情越應該由架構師預先搞定，否則就容易做無用功，對開發工作產生致命傷害。具體來講這類事情由三個核心部分組成：
- 選定Tech Stack
- 概要設計，確立分工的基礎
- 協同方式
選定Tech Stack是指要選定包括程式語言，基本框架等一系列東西，比如Trello選完之後大致是下面這個樣子：
圖片來自網路（出處）
這事情幾乎是不可重置的，因為重置成本已經到了正常團隊不可能負擔的地步。所以Tech Stack與待開發產品的吻合程度是非常體現架構師價值的地方。選了Tech Stack但發現無法達成產品目標是架構設計上最差的結果，也正因為輸不起，在這個環節上可以慎重些。這種Tech Stack的選擇受限於上述所說的關鍵需求，比如快，支援移動端等。也就是常說的從需求的模型想技術模型的對映。
瞭解些技術的應該一眼可以看出來上面這張圖是MEAN（MongoDB，Express，AngularJS。。。，NodeJS）架構，這架構滿足上面關鍵需求是沒問題的，但如果關鍵需求裡有一條叫以靈活的外掛結構來滿足不同使用者的定製化需求，上面這架構可能就有點麻煩了。
不管怎麼樣Tech Stack架構師第一個需要搞定的事情，沒這個什麼活也幹不了。
再其次則是相對比較傳統一點的部分，不管從哪裡開始迭代，總是要切分前端後端的職責，設計彼此互動的介面，要區分出來哪些是純工具型的模組（比如日誌），哪些是基礎設施型的（比如使用者管理與許可權），哪些是可以徹底進行迭代的（比如具體的某個功能）。這些東西之間是有一種內在的時序關聯的，不是簡單一句：我們迭代吧，我們測試驅動開發吧，就可以的，那會導致很大的混亂，所以這裡也是架構師要扮演角色的地方。傳統上管這個叫概要設計，雖然這詞現在不怎麼用了，但這詞其實還不錯的。當然架構師不一定要一個人搞定所有這些事情，而是要肩負起協調大家搞定這些事情的職責。這個地方依賴於產品的型別對業務知識的要求程度不同：一般來講越是面向個人的產品，在業務知識上要求越低；越是面向企業的產品業務知識的要求越高。簡單講做天氣應用的時候可能直接做就行了，但做財務應用時瞭解財務的某些知識就挺必須的。
最後一項則是分工後的一種協作的方法，這裡麵包含著分支策略，持續整合策略等。
顯然的，下面兩種分支策略下，團隊的協作方式不一樣.。
圖片來自網路（出處）
這是又一個全域性性的工作，幹活前需要預先定下來應該也是沒疑問的，但是不是架構師搞定這事上，不同人的認知可能會不一樣，有的人會認為應該是專案經理類的角色來搞定這事情。我個人則堅持認為理想情形下應該架構師搞定這事，因為分支策略等受技術的約束更大。
這就是我理解中架構師的要乾的三類活：選擇Tech Stack，概要設計來確立分工的基礎，確立協同的方式。
在開發產品時，這三樣事情不搞定，迭代都不好迭代。抽象點來看是這樣：假設說在現有人員的基礎上，預先搞定某問題需要耗費的成本為X，而迭代後，事到臨頭再處理，其耗費的成本為Y，那麼無疑的Y>X的問題都應該是儘可能預先處理的問題，而不能以迭代為藉口堂而皇之的進行忽視。而上述三方面問題，基本上是Y>X這類。
如何成為架構師？
首先想說的是程式設計師不一定要成為架構師的，優秀的程式設計師一樣很有價值，但關鍵要看技術領域，我在程式設計師可以只關心技術麼？ 專門說過這事，這裡不再展開。
真要想成為架構師事實上總是有兩類方法，這兩類方法倒不侷限於架構師的學習，而是普適於任何學習。
一種是從概念規則到實踐，一種則是從實踐總結出概念和規則。數學更近似前者，而歷史更近似後者。當我們試圖先抽象出什麼是架構設計，架構設計又有那些原則，之後再讓大家瞭解現實中的架構設計如何做時，無疑的採取的也是前者的方式，也就是數學的方式。這種方式在現實中比較常見，但在邏輯上是有問題的：正是因為對架構設計的不理解，才嘗試學習架構設計，即如此想學習的人天生在瞭解架構設計的概念與原則會遭遇困難。
出於這樣一種考慮，最好的辦法其實是先了解一些最基本概念，比如前面說的那些，再瞭解一些最基本的原則，比如：正交，資訊隱藏等。之後就不在抽象概念層面打轉了。而瞭解多個現有典型產品的架構，比如上面說的Trello，WordPress等。這時候最好對產品歸類，在特定類別下抽象出來一些典型的架構模式。比如：軟硬一體產品的架構，CMS的架構等。這樣一來，如果一個人可以主要學習其中之一，順道瞭解其餘，那就可以比較迅速的掌握架構設計的知識，至少是上面說的架構設計中的前兩類知識：Tech Stack的選擇與概要設計。在開源的時代裡，這已經成為一個人坐在家裡就可以完成的事情了。
一點呼籲
最後做一點呼籲。現在各種架構設計的課程還是比較多的，但基本上都是按照第一條思路來的，比如：講架構設計時會去嘗試把架構設計分解為邏輯架構，執行架構等。從身邊人的效果來看，普遍不太理想。有實力的培訓機構可以嘗試總結架構的模式，以一個總綱帶領幾個典型領域的架構分析，比如：CMS就參照WordPress來講架構，基礎JavaScript庫就參照Backbone這種等。也不用太多，覆蓋典型的4~5個領域就可以解決很大的問題了。這應該會更有效果，但課程建立上會比較吃力些，真想做的人要有思想準備。我個人曾經嘗試和南京的TalenCamp按照第二條路來設計課程，但由於各種原因暫時進展不太大。
作者介紹：李智勇，V眾投發起人，《完美軟體開發：方法與邏輯》作者。
來自：CSDN
相關閱讀
評論(1)