許式偉，七牛雲 CEO，ECUG 社區發起人，國內 Go 語言實踐圈子公認的語言專家，著有《 Go 語言編程》；超過 10 年互聯網從業經驗，曾在金山、盛大從事技術研究方面的工作，是 WPS 2005 的首席架構師，於 2011 年創辦七牛雲。本文整理自許式偉在GTLC全球技術領導力峯會上的演講。
從軟件工程說起
大家好！
我已經很久沒有做技術類的演講了，因爲我最近確實比較忙，很少會出來。爲什麼會突然又想談一下架構呢？這是我個人的宿願，我是技術出身，雖然現在比較少寫技術相關的東西，但我在公司內部做了很多分享，分享課裏我講的東西與架構相關的佔三分之二，基本都是和架構相關的。
所以今天借這個機會談一談我自己理解的架構到底是什麼。
國內現在比較少真正意義上符合 “架構師” 這個詞的定位的角色，我們的教育和工作氛圍很難出真正意義上的架構師，比較鳳毛麟角。我自己理解的架構師是從軟件工程概念開始的，也許大家都學過軟件工程，但如果我們把軟件工程這門課重新看待，這門學科到底談的是什麼？是軟件項目管理的方法論？
無論如何，軟件工程是一門最年輕的學科，相比其他動輒跨世紀的自然科學而言，軟件工程只有 50 年的歷史。這門學科的實踐太少了，任何一門學科的實踐時間短的話，都很難沉澱出真正有創意的實踐總結，因爲這些經驗總結總是需要很多代人共同推動來完成。
爲什麼只有 50 年時間呢？我們來看看 C 語言，一般意義上可能認爲它是現代語言的開始。C 語言誕生於 1970 年，到現在是 49 年。再看 Fortran，它被認定爲第一個高級語言，誕生於 1954 年，那時候主要面向的領域是科學計算。Fortran 的程序代碼量不大，量不大的時候談不上工程的概念。這也是爲什麼軟件工程這門學科很年輕，它只有 50 歲，在這樣一個年輕的學科裏我們對它的認知肯定還是非常膚淺的。
我在極客時間裏的課程裏一上來就做了軟件工程和建築工程的對比。對比可以發現二者有非常大的區別，具體在於兩點：
（1）快速變化。建築工程在完工以後就結束了，基本上很少會進行變更，除非對它進行軟裝上的變更，軟裝更像是今天的軟件。但其實軟件工程裏，軟件生產出來只是開始，而且只要軟件的生命週期沒有結束，變更就一直存在，很像建築裏的軟裝一樣，而且比軟裝變化劇烈得多。
（2）不確定性。爲什麼軟件工程有很大的不確定性？因爲沒有兩個人的工作是一樣的，雖然大家都在編程，但是編程的內容是不一樣的。每個人昨天和今天的工作也是不一樣的，沒有人會寫一模一樣的代碼，我們總是不停地寫新的東西，做新的工作。這些東西是非常不同的，軟件工程從事的是創造性的工作。
大家都知道創造是很難的，創造意味着會有大量的試錯，因爲我們沒有做過。這會導致軟件工程有非常大的不確定性。
以上這兩點都會導致軟件工程區別於傳統意義上的所有工程，有非常強的管理難度。過去那麼多年，工業界有非常多的工程實踐，但是所有的工程實踐對軟件工程來說都是不適用的，因爲二者有很大的不一樣。
今天站在管理的視角再看軟件工程，我們知道管理學談的是確定性，我們如何去創造確定性是管理學中的追求，否則管理管什麼呢？某種意義上來說管理學的目的就是要抑制不確定性，產生確定性。比如說開發的工期，時間成本是否能確定。其次，人力成本，研發成本和後期運維的成本是不是確定性的。所以軟件項目的管理又期望達到確定性。這是一對矛盾。軟件工程本身是快速變化的，是不確定的。但是軟件工程管理又希望得到確定性，這就是軟件工程管理上的矛盾。我們的目標是在大量的不確定性中找到確定性，這是我認爲這件事情最核心的點。
程序員的三個層次
軟件工程管理到底在管什麼？和所有的管理活動一樣 無非就是人和事。所有的工程項目都希望找到最好的人，當然是在能給出的預算以內找到最好的人，有的人可能找不起。不同項目最大的差別就是事，不同的事在哪裏？從做事的角度來講我們招到的人可能會分三個層次（程序員三個級別），大家經常開玩笑說我是做搬磚的，所以第一個 level 我把他叫軟件搬磚師，再然後是軟件工程師、軟件架構師。
軟件搬磚師可以有很多。但今天數量其實還不算太多，因爲我們知道這門學科只有 50 年的歷史。但是好的一點是，產生軟件搬磚師並不難，我做了一個長達四年的實踐：從小學二年級開始教小學生編程。結論是做搬磚師不難，小學生也能做到。這是很有意思的一件事情，編程並不是非常複雜的學問，只要具備基本的邏輯能力，把常規的業務代碼按部就班地壘出來，基本上可以算打到搬磚師水準。我自己認爲這並不難。
軟件工程師會相對難一些，我心目中的軟件工程師首先在代碼上會非常追求可讀性、可維護性。另外，畢竟我們工程是羣體協作，所以在羣體協作上還是有自己的方法論和思考。比如說代碼評審、單元測試。在我看來搬磚師和工程師的區別有很大不同。只要看他寫的代碼有沒有注意可維護性，會和同伴交流的時候刻意去追求讓同伴更好地理解自己的思想，是不是對單元測試比較抗拒，是不是比較樂意去做代碼評審並且非常認同這件事情的價值，基本上通過這些事情就可以評判這個人是搬磚師還是工程師。
軟件架構師的能力要求
談到軟件架構師，由於我畢業後兩年在從事架構性質的工作，因此對軟件架構師的特性有一些總結。首先在用戶需求上，有判斷能力和預見能力，此處的判斷可以理解爲對需求的鑑別，雖然這可能與產品經理最爲相關，但架構師需要具備自己的判斷力，當然這也包括對未來需求的預見能力；產品迭代上，有規劃能力，判斷需求哪些應該先滿足，哪些後滿足。架構師應該源於程序員，但不應侷限於程序員視角。系統設計上，有分解和組合能力。技術選型上，有決策力。技術選型應該被認爲是架構的一部分，我們非常反對開發人員隨意選用開源組件，這是一件需要認真探討的事情。人力資源上，有統籌能力，通俗地講是 “看菜做飯（看人下菜）”。
綜上不難看出，架構師對綜合能力要求比較高。這是因爲我認爲架構師需要對軟件工程的結果負責，在不確定性和快速變化中尋找確定性。全局看軟件發佈流程，其比較重要的子過程有：需求分析（需求梳理 => 產品定義），系統設計（子系統劃分 => 模塊定義），模塊設計（模塊詳細設計），編碼實現，單元測試，代碼評審，集成測試，灰度發佈，正式發佈等一系列過程。雖然有些過程看起來不屬於架構師的範疇，但是這些活動過程屬於軟件工程的一部分，架構師一樣需要全面參與把控。如果沒有架構師把控就沒有人觀察得到全貌。正因爲如此，軟件架構師的要求相對較高。
如上所言，軟件架構師需要具備產品經理的部分能力，因爲需要對用戶需求進行分析，並進行判斷和預判，以及對產品迭代優先級進行把控。我自己習慣用如下圖片表達軟件架構師和產品經理之間的關係：
我認爲，產品是“橋”，連接了兩端，分別是用戶需求和先進的技術。我一直認爲，用戶需求的變化非常緩慢，那麼爲什麼產品會產生迭代？這是因爲技術在迭代。本質上講，產品迭代是技術迭代導致的需求滿足方式的變化，所以產品實際上是一種需求滿足的方式。
從這個意義上講，架構師更多是從技術方案的角度看產品，而產品經理更多是從用戶需求來看，但二者一定會碰頭，只要能力提升到角色所期望的樣子，越厲害就越具備兩側的能力。所以我認爲，產品經理和架構師是一體兩面，本質上對人的能力、訴求是相通的。產品經理在做產品架構，架構師在做技術架構，但最終目的一樣。
從產品和需求視角看架構師
如果展開講解產品定義過程，首先需要進行需求梳理，關心用戶反饋。但是，很多用戶反饋並不代表其根本性需求。有很多用戶反饋需求的時候，往往已經帶着他自己給出的解決方案。這種需求反饋已經屬於二次加工的需求，而非原始需求。這個時候我們要多問多推敲，把它還原到不帶任何技術實現假設的根源需求。
如上圖所示，根源需求可能會有非常非常多的技術方案可以滿足它。我們上面示意圖中的小圓點是一個個用戶反饋的需求。在用戶提這些需求的時候，往往可能會帶着他熟悉的技術方案的烙印。
產品都是通過提供相應的技術方案在滿足用戶的根源訴求，但技術一直在迭代進步，從而導致原有的解決方案過時落後，這種情況下需要新的解決方案出現。如果對用戶反饋的需求全部滿足，產品就會變得十分龐大，編程一個四不像的東西。
其次，在這個過程中，有些用戶需求是穩定的，有些是變化的。舉例來說，計算機系統結構從計算機誕生之後到現在沒變過，但電子設備的形態發生了很大變化，從最早的大型機，到個人電腦，到筆記本，到手機，再到手錶，形態變化劇烈。但爲什麼計算機系統結構能夠適應需求而不用改變架構，這其實是非常值得思考的事情，其根源就是對變化點的抽象，找到系統需求的變化點，預見變化並做對應的開放式設計。本質上講，架構師關心產品的核心根源就是預測變化。
最後，理清產品邊界。同樣以計算機爲例，經過多輪迭代，多樣化外設（鍵盤等）變化較大，但 CPU、內存演進較小，所以在變化點上做相應的開放式設計是必要的。同樣的，需要與合作伙伴做邊界設定，把變化開放出去讓合作伙伴做，只有這樣的產品才能達到較好效果。
從產品和解決方案角度來看，產品往往需要適應很多行業，但這個過程會讓產品變得非常龐大。在我看來，產品應該爲行業解決方案提供能力，行業解決方案優先選擇合作伙伴做，以更加開放的心態看待這件事情，避免把行業方案視作產品的一部分。
梳理需求中比較關鍵的點是市場策略，需要解決的需求有非常多現成的方案，但哪些方案是主流的，哪些是最關鍵的都需要思考。雖然不能放大產品需求覆蓋面，但也需要爲某些關心既有市場的玩家做橋樑，這些橋樑也是產品的功能點。我傾向於認爲關鍵市場可能會把既有玩家的能力適配到產品上作爲很重要的功能，但是大部分市場主流方案我們還是提供“橋”，而不是自己解決掉。
從技術視角看架構師
以上是從產品和需求維度看架構師，從技術視角看，架構師很重要的能力是具備技術的全局視角，所謂的技術全貌是指從底到上的核心骨架，比如最底下的硬件結構、操作系統、編程語言，甚至瀏覽器等，只有掌握每一層的核心思想，才能在架構設計中沒有技術盲點。
從培養架構師的角度來看，爲什麼真正意義上的架構師比較難找？這是因爲需要構建兩個層次的能力：
1、懂用戶、懂市場，有一定市場洞察能力。作爲技術人員，可能會不自覺、甚至不願意和用戶打交道，更希望坐在家裏安靜碼代碼。但是，作爲架構師，不和用戶打交道，成長會比較受限，不接觸用戶就無法理解用戶需求，親自和用戶打交道傾聽來的需求和探討完全不一樣。因此，架構師要尊重用戶反饋，並學會思考需求分析和推演，這比技術能力更重要。架構的第一步就是需求分析，如果需求分析沒做好，後續自然沒辦法做得很極致。
2、建立技術上的全局視角。
以上兩點是架構師最核心的兩個能力。
最後，我要介紹下，最近我在極客時間上開設了架構課，到現在爲止剛好第一章全部發布。專欄內容的結構基本是相互交織的兩條線索：
1、信息世界的構建過程，從底層硬件到操作系統逐層遞進，還原信息世界的構建歷程，主要關注宏觀結構及需求變化，每一層都經歷了哪些變化；
2、架構方法論。如果我們純講架構方法論，容易過度抽象，比如什麼開閉原則、單一職責原則之類。所以我們要結合信息世界的構建過程講，它本身就是最宏大的架構實踐案例。
以上就是我的演講內容，謝謝大家。