七牛雲許式偉：我所理解的架構是什麼

從軟件工程提及

你們好！

我已經好久沒有作技術類的演講了，由於我最近確實比較忙，不多會出來。爲何會忽然又想談一下架構呢？這是我我的的宿願，我是技術出身，雖然如今比較少寫技術相關的東西，但我在公司內部作了不少分享，分享課裏我講的東西與架構相關的佔三分之二，基本都是和架構相關的。

因此今天借這個機會談一談我本身理解的架構究竟是什麼。

國內如今比較少真正意義上符合 「架構師」 這個詞的定位的角色，咱們的教育和工做氛圍很難出真正意義上的架構師，比較百裏挑一。我本身理解的架構師是從軟件工程概念開始的，也許你們都學過軟件工程，但若是咱們把軟件工程這門課從新看待，這門學科到底談的是什麼？是軟件項目管理的方法論？

不管如何，軟件工程是一門最年輕的學科，相比其餘動輒跨世紀的天然科學而言，軟件工程只有 50 年的歷史。這門學科的實踐太少了，任何一門學科的實踐時間短的話，都很難沉澱出真正有創意的實踐總結，由於這些經驗總結老是須要不少代人共同推進來完成。

爲何只有 50 年時間呢？咱們來看看 C 語言，通常意義上可能認爲它是現代語言的開始。C 語言誕生於 1970 年，到如今是 49 年。再看 Fortran，它被認定爲第一個高級語言，誕生於 1954 年，那時候主要面向的領域是科學計算。Fortran 的程序代碼量不大，量不大的時候談不上工程的概念。這也是爲何軟件工程這門學科很年輕，它只有 50 歲，在這樣一個年輕的學科裏咱們對它的認知確定仍是很是膚淺的。

我在極客時間裏的課程裏一上來就作了軟件工程和建築工程的對比。對比能夠發現兩者有很是大的區別，具體在於兩點：

（1）快速變化。建築工程在完工之後就結束了，基本上不多會進行變動，除非對它進行軟裝上的變動，軟裝更像是今天的軟件。但其實軟件工程裏，軟件生產出來只是開始，並且只要軟件的生命週期沒有結束，變動就一直存在，很像建築裏的軟裝同樣，並且比軟裝變化劇烈得多。

（2）不肯定性。爲何軟件工程有很大的不肯定性？由於沒有兩我的的工做是同樣的，雖然你們都在編程，可是編程的內容是不同的。每一個人昨天和今天的工做也是不同的，沒有人會寫如出一轍的代碼，咱們老是不停地寫新的東西，作新的工做。這些東西是很是不一樣的，軟件工程從事的是創造性的工做。

你們都知道創造是很難的，創造意味着會有大量的試錯，由於咱們沒有作過。這會致使軟件工程有很是大的不肯定性。

以上這兩點都會致使軟件工程區別於傳統意義上的全部工程，有很是強的管理難度。過去那麼多年，工業界有很是多的工程實踐，可是全部的工程實踐對軟件工程來講都是不適用的，由於兩者有很大的不同。

今天站在管理的視角再看軟件工程，咱們知道管理學談的是肯定性，咱們如何去創造肯定性是管理學中的追求，不然管理管什麼呢？某種意義上來講管理學的目的就是要抑制不肯定性，產生肯定性。好比說開發的工期，時間成本是否能肯定。其次，人力成本，研發成本和後期運維的成本是否是肯定性的。因此軟件項目的管理又指望達到肯定性。這是一對矛盾。軟件工程自己是快速變化的，是不肯定的。可是軟件工程管理又但願獲得肯定性，這就是軟件工程管理上的矛盾。咱們的目標是在大量的不肯定性中找到肯定性，這是我認爲這件事情最核心的點。

程序員的三個層次

軟件工程管理到底在管什麼？和全部的管理活動同樣 無非就是人和事。全部的工程項目都但願找到最好的人，固然是在能給出的預算之內找到最好的人，有的人可能找不起。不一樣項目最大的差異就是事，不一樣的事在哪裏？從作事的角度來說咱們招到的人可能會分三個層次（程序員三個級別），你們常常開玩笑說我是作搬磚的，因此第一個 level 我把他叫軟件搬磚師，再而後是軟件工程師、軟件架構師。

軟件搬磚師能夠有不少。但今天數量其實還不算太多，由於咱們知道這門學科只有 50 年的歷史。可是好的一點是，產生軟件搬磚師並不難，我作了一個長達四年的實踐：從小學二年級開始教小學生編程。結論是作搬磚師不難，小學生也能作到。這是頗有意思的一件事情，編程並非很是複雜的學問，只要具有基本的邏輯能力，把常規的業務代碼循序漸進地壘出來，基本上能夠算打到搬磚師水準。我本身認爲這並不難。

軟件工程師會相對難一些，我心目中的軟件工程師首先在代碼上會很是追求可讀性、可維護性。另外，畢竟咱們工程是羣體協做，因此在羣體協做上仍是有本身的方法論和思考。好比說代碼評審、單元測試。在我看來搬磚師和工程師的區別有很大不一樣。只要看他寫的代碼有沒有注意可維護性，會和同伴交流的時候刻意去追求讓同伴更好地理解本身的思想，是否是對單元測試比較抗拒，是否是比較樂意去作代碼評審而且很是認同這件事情的價值，基本上經過這些事情就能夠評判這我的是搬磚師仍是工程師。

軟件架構師的能力要求

談到軟件架構師，因爲我畢業後兩年在從事架構性質的工做，所以對軟件架構師的特性有一些總結。首先在用戶需求上，有判斷能力和預見能力，此處的判斷能夠理解爲對需求的鑑別，雖然這可能與產品經理最爲相關，但架構師須要具有本身的判斷力，固然這也包括對將來需求的預見能力；產品迭代上，有規劃能力，判斷需求哪些應該先知足，哪些後知足。架構師應該源於程序員，但不該侷限於程序員視角。系統設計上，有分解和組合能力。技術選型上，有決策力。技術選型應該被認爲是架構的一部分，咱們很是反對開發人員隨意選用開源組件，這是一件須要認真探討的事情。人力資源上，有統籌能力，通俗地講是 「看菜作飯（看人下菜）」。

綜上不難看出，架構師對綜合能力要求比較高。這是由於我認爲架構師須要對軟件工程的結果負責，在不肯定性和快速變化中尋找肯定性。全局看軟件發佈流程，其比較重要的子過程有：需求分析（需求梳理 => 產品定義），系統設計（子系統劃分 => 模塊定義），模塊設計（模塊詳細設計），編碼實現，單元測試，代碼評審，集成測試，灰度發佈，正式發佈等一系列過程。雖然有些過程看起來不屬於架構師的範疇，可是這些活動過程屬於軟件工程的一部分，架構師同樣須要全面參與把控。若是沒有架構師把控就沒有人觀察獲得全貌。正由於如此，軟件架構師的要求相對較高。

如上所言，軟件架構師須要具有產品經理的部分能力，由於須要對用戶需求進行分析，並進行判斷和預判，以及對產品迭代優先級進行把控。我本身習慣用以下圖片表達軟件架構師和產品經理之間的關係：

我認爲，產品是「橋」，鏈接了兩端，分別是用戶需求和先進的技術。我一直認爲，用戶需求的變化很是緩慢，那麼爲何產品會產生迭代？這是由於技術在迭代。本質上講，產品迭代是技術迭代致使的需求知足方式的變化，因此產品其實是一種需求知足的方式。

從這個意義上講，架構師更可能是從技術方案的角度看產品，而產品經理更可能是從用戶需求來看，但兩者必定會碰頭，只要能力提高到角色所指望的樣子，越厲害就越具有兩側的能力。因此我認爲，產品經理和架構師是一體兩面，本質上對人的能力、訴求是相通的。產品經理在作產品架構，架構師在作技術架構，但最終目的同樣。

從產品和需求視角看架構師

若是展開講解產品定義過程，首先須要進行需求梳理，關心用戶反饋。可是，不少用戶反饋並不表明其根本性需求。有不少用戶反饋需求的時候，每每已經帶着他本身給出的解決方案。這種需求反饋已經屬於二次加工的需求，而非原始需求。這個時候咱們要多問多推敲，把它還原到不帶任何技術實現假設的根源需求。

如上圖所示，根源需求可能會有很是很是多的技術方案能夠知足它。咱們上面示意圖中的小圓點是一個個用戶反饋的需求。在用戶提這些需求的時候，每每可能會帶着他熟悉的技術方案的烙印。

產品都是經過提供相應的技術方案在知足用戶的根源訴求，但技術一直在迭代進步，從而致使原有的解決方案過期落後，這種狀況下須要新的解決方案出現。若是對用戶反饋的需求所有知足，產品就會變得十分龐大，編程一個四不像的東西。

其次，在這個過程當中，有些用戶需求是穩定的，有些是變化的。舉例來講，計算機系統結構從計算機誕生以後到如今沒變過，但電子設備的形態發生了很大變化，從最先的大型機，到我的電腦，到筆記本，到手機，再到手錶，形態變化劇烈。但爲何計算機系統結構可以適應需求而不用改變架構，這實際上是很是值得思考的事情，其根源就是對變化點的抽象，找到系統需求的變化點，預見變化並作對應的開放式設計。本質上講，架構師關心產品的核心根源就是預測變化。

最後，理清產品邊界。一樣以計算機爲例，通過多輪迭代，多樣化外設（鍵盤等）變化較大，但 CPU、內存演進較小，因此在變化點上作相應的開放式設計是必要的。一樣的，須要與合做夥伴作邊界設定，把變化開放出去讓合做夥伴作，只有這樣的產品才能達到較好效果。

從產品和解決方案角度來看，產品每每須要適應不少行業，但這個過程會讓產品變得很是龐大。在我看來，產品應該爲行業解決方案提供能力，行業解決方案優先選擇合做夥伴作，以更加開放的心態看待這件事情，避免把行業方案視做產品的一部分。

梳理需求中比較關鍵的點是市場策略，須要解決的需求有很是多現成的方案，但哪些方案是主流的，哪些是最關鍵的都須要思考。雖然不能放大產品需求覆蓋面，但也須要爲某些關心既有市場的玩家作橋樑，這些橋樑也是產品的功能點。我傾向於認爲關鍵市場可能會把既有玩家的能力適配到產品上做爲很重要的功能，可是大部分市場主流方案咱們仍是提供「橋」，而不是本身解決掉。

從技術視角看架構師

以上是從產品和需求維度看架構師，從技術視角看，架構師很重要的能力是具有技術的全局視角，所謂的技術全貌是指從底到上的核心骨架，好比最底下的硬件結構、操做系統、編程語言，甚至瀏覽器等，只有掌握每一層的核心思想，才能在架構設計中沒有技術盲點。

從培養架構師的角度來看，爲何真正意義上的架構師比較難找？這是由於須要構建兩個層次的能力：

一、懂用戶、懂市場，有必定市場洞察能力。做爲技術人員，可能會不自覺、甚至不肯意和用戶打交道，更但願坐在家裏安靜碼代碼。可是，做爲架構師，不和用戶打交道，成長會比較受限，不接觸用戶就沒法理解用戶需求，親自和用戶打交道傾聽來的需求和探討徹底不同。所以，架構師要尊重用戶反饋，並學會思考需求分析和推演，這比技術能力更重要。架構的第一步就是需求分析，若是需求分析沒作好，後續天然沒辦法作得很極致。

二、創建技術上的全局視角。

以上兩點是架構師最核心的兩個能力。

最後，我要介紹下，最近我在極客時間上開設了架構課，到如今爲止恰好第一章所有發佈。專欄內容的結構基本是相互交織的兩條線索：

一、信息世界的構建過程，從底層硬件到操做系統逐層遞進，還原信息世界的構建歷程，主要關注宏觀結構及需求變化，每一層都經歷了哪些變化；

二、架構方法論。若是咱們純講架構方法論，容易過分抽象，好比什麼開閉原則、單一職責原則之類。因此咱們要結合信息世界的構建過程講，它自己就是最宏大的架構實踐案例。

以上就是個人演講內容，謝謝你們。

 出處：https://www.infoq.cn/article/scbBuLydXi00sZ4v*UyN