分享七牛云CEO「許式偉」對于這個話題的思考。
你好，我是許式偉。從今天起，我想和你一起來聊聊架構的話題。
開始之前，我先來和你簡單介紹下我自己。
我是2000年開始工作的，曾經做過wps的首席架構師，也在盛大從事過技術研究方面的工作，后來在2011年創立了七牛云，現在我是一名創業者、CEO。但不管角色怎么輪換，我覺得我的另一面始終是一名程序員、架構師。
讓我們來想象一下，如果把信息世界看成一座大廈，把程序員看成這個世界的建筑師，那么，現在的你在負責什么樣的工作呢？
當我們把程序員類比成建筑師時，按照能力水平來分，我覺得大體可以分為三個層次：搬磚師、工程師、架構師。
軟件搬磚師之名對應到建筑行業的建筑工人，他們的編程能力和業務基本上停留在堆疊代碼，按照要求去實現功能需求的層面。
只要能讓程序跑起來，能正確地實現業務邏輯，就可以稱為“會編程”的人。有時候，我們也會看見程序員自稱為“碼農”“搬磚的”，雖然二者的工種不同，但從基礎工作的相似度來說，確實有可類比的成分。
很多外行的人都會覺得程序員是一個很神秘的職業，但實際上程序員的基礎門檻并不算高。我自己從2016年2月開始至今，一直在教幾位8~12歲的小朋友學習編程。這個實踐經驗告訴我：小學生完全有能力學編程。而且，并不是只有部分小學生可以，而是任何一位小學生都可以學會。
然而，只讓代碼跑起來是不夠的。這個世界是不斷變化的，作為程序員，我們更多的時間是用來維護代碼：增加新的需求，對已有的功能進行調整，修改之前代碼遺留下來的問題，優化性能等等。
這是因為一個軟件誕生之后，后續就是需要花費大量的代價去維護它，演進它。一個人是完全維護不過來的，需要更多的人，很多的團隊一起協作。如果面臨了員工離職、崗位調整等情況，還會導致軟件代碼在不同人之間流轉。
所以，一些有追求的程序員會關注代碼的質量。代碼質量的評判可以有這樣一些基本維度：可閱讀性（方便代碼流轉）、可擴展性/可維護性（方便修改功能，添加新功能）、可測試性（質量管理）、可復用性（簡化后續功能開發的難度）。
這一類致力于不斷提升軟件代碼的工程質量的程序員，我們可以稱他們為軟件工程師。
工程師不會簡單把寫代碼看作一門工作，把任務交代過去就完事。他們會有“潔癖”，代碼在他們眼里是一種藝術，是自己生命的一部分。
他們會把寫出來的代碼改了又改，直到讓自己滿意為止。閱讀和維護軟件工程師寫的代碼會有一種賞心悅目的感覺。
但是，大部分商業軟件都是一項極其復雜的工程，它們遠比很多傳統的建筑工程復雜得多，無論是涉及的人力、時間還是業務的變數都要多很多。
人力上，大部分大型的軟件系統都有幾千甚至幾萬人的規模，而這幾千幾萬人中，卻沒有兩個人的工作是重復的，他們都是在從事著前所未有的創造性工作。
時間上，只要軟件還在服務客戶中，程序員們的創造過程便不會停止，軟件系統仍然持續迭代更新，以便形成更好的市場競爭力。
這些都與傳統建筑工程的模式大相徑庭。一幢建筑自它完成之后，所有的變化便主要集中在一些軟裝的細節上，很少會再發生劇烈的變動，更不會持續地發生變動。但軟件卻不是這樣，它從誕生之初到其生命周期結束，自始至終都在迭代變化，從未停止。
所以，光靠把控軟件工程師的水平，依賴他們自覺保障的工程質量，是遠遠不夠的。軟件工程是一項非常復雜的系統工程，它需要依賴一個能夠掌控整個工程全局的團隊，來規劃和引導整個系統的演變過程。這個團隊就是架構師團隊。
軟件架構師的職責，并不單單是我們通常理解的，對軟件系統進行邊界劃分和模塊規格的定義。
從根本目標來說，軟件架構師要對軟件工程的執行結果負責，這包括：按時按質進行軟件的迭代和發布、敏捷地響應需求變更、防范軟件質量風險（避免發生軟件質量事故）、降低迭代維護成本。
那怎么才能成長為優秀的軟件架構師？軟件架構師和軟件工程師最根本的差別又在哪里？我認為關鍵在于四個字：掌控全局。
掌控全局，就是對系統的全貌了然于胸。從傳統的建筑工程來說，建筑架構師并不單單要會畫建筑圖紙，而是要對地基構建、土質、材料、建筑工藝等等所有有可能影響建筑質量的因素都要了然于胸。
掌控全局，并不是無所不能，不是成為全棧。怎么做到掌控全局？核心在于對知識脈絡的體系化梳理。這是架構能力構建和全面提升的關鍵。這種方法不單單是在軟件工程中適用。
比如學數學，我個人非常喜歡做的一件事情是自己去推導書上所有的公式。每一個公式我都親自推導而來。
這樣做的核心意義在于，我在嘗試從0開始，去構建整個精彩紛呈的數學世界，整個數學發展史在自己的筆下重新演繹了一遍，來龍去脈清清楚楚。有時候你甚至會推導出還沒有學到的公式，但是在后面學到了。這種體驗非常有趣而又讓人滿足。
是的，掌控全局的前提是：在自己心中去重新構建出整個世界。在這個過程中，你不需要一上來沉浸在某個技術的實現細節（除非它影響了你對這個世界構建過程的理解），但是你知道整個世界的脈絡，知道整個世界的骨架。
這個時候，你對這個世界的感覺是完全不同的，因為，你已經成為了這個世界的構建者。
而架構的本質，不也正是構建和創造么？
作為一個軟件行業的從業人員，我們可能接觸各種各樣的技術書籍。有講編程語言的、講數據結構與算法的、講操作系統的、講編譯原理的、講架構設計的，還有領域技術類的（比如數據庫、存儲、大數據、人工智能之類）。
大部分類別的技術書，多多少少都能夠找到幾本經典著作。但是，架構設計很可能是個例外，當我想推薦一本經典的架構設計書時，我并不能非常快速地想到應該推薦哪本。
從個人經驗來說，我接觸過的與架構相關的圖書，大概有如下這些分類。
- 架構思維類。這類圖書通常從一些著名的架構理論講起，比如開閉原則、單一職責原則、依賴倒置原則、接口分離原則，等等。這種圖書的問題在于過度理論化。計算機科學歸根到底屬于工程技術類，實踐第一。
- 設計模式類。這一類圖書則一下子進入架構的局部細節，每個模式的來龍去脈并不容易理解。就算理解了某個具體的模式，但是也很難真正做到活學活用，不知道還是不知道。
- 分布式系統架構設計類。這類圖書通常從服務端的通用問題如一致性、高可用、高并發挑戰等話題講起，講大型業務系統面臨的挑戰。這些知識是非常有價值的，但無法延伸到通用業務架構，對大部分企業的架構實踐并不具備真正的指導意義。
- 重構類。這類圖書主要講怎么把壞代碼一步步改進到好代碼。我認為這是最實用的一類。但在沒有優秀架構師主導的情況下，大部分公司的代碼不可避免地越變越壞，直到不堪重負最后不得不重寫。實際上，一個模塊最初的地基是最重要的，基本決定了這座大廈能夠撐多久，而重構更多側重于大廈建成之后，在服務于人的前提下怎么去修修補補，延長生命。
這些架構類的圖書并沒有達到我個人的期望。因為它們都沒有揭開架構設計的全貌。
我自己在職業生涯中前后大概做過十幾次的架構類演講，這也是我最為重視、重復次數最多的一類演講。但同樣地，這樣零星的演講對于傳遞架構設計思想來說，仍然遠遠不夠。
所以一直以來，我就心存著這樣一個念頭：“要寫一本不一樣的架構類圖書”。這個念想，也正是今天這個專欄的由來。
這個專欄的內容組織算是我的一次嘗試。它和今天你看得到的大部分架構書并不太一樣。我基本上圍繞著兩個脈絡主線來展開內容：
- 如何從零開始一步步構建出整個信息世界；
- 在整個信息世界的構建過程中，都用了哪些重要的架構思維范式，以及這些范式如何去運用于你平常的工程實踐中。
這兩大脈絡相輔相成。首先，我們通過還原信息世界的構建過程，剝離出了整個信息世界的核心骨架，這也是最真實、最宏大的架構實踐案例。其次，我們結合這個宏大的架構實踐來談架構思維，避免因對架構思維的闡述過于理論化而讓人難以理解。
我想，每個程序員都有一顆成為架構師的心。所以，從內容設計來說，我希望這是一個門檻最低的架構設計專欄，也希望它可以幫助到想成為架構師的初學者，達成自己的目標。
在行文上，我會盡量避免深奧的術語，盡可能以通俗易懂的文字，來描述信息世界構建者們的所思所想。如果你在閱讀的過程中遇到了理解上的障礙，非常歡迎你來給我留言，我將盡可能地根據你的反饋，做出必要的調整。
如果你已經成為了架構師，我也希望可以為你規避一些錯誤的經驗。在過去的工作經歷里，我看到不少架構師都會傾向于把架構看作一項純技術性的行為。他們的工作流程是這樣的：產品經理根據用戶的需求做出產品設計，然后架構師再依據產品設計給出實現，也就是軟件的架構設計方案。
在我看來，這其實是個誤解。架構關乎的是整個復雜的軟件工程，它關乎實現它的人，它又因團隊的能力而異。
同時，架構也關乎用戶需求，作為架構師，我們不只是要知道當前的用戶需求是什么，我們還要預測需求未來可能的變化，預判什么會發生，而什么一定不會發生。預測什么不會發生最為重要，只有做到這一點，才能真正防止架構的過度設計，把簡單的事情復雜化。
談了這么多，那么，應該怎樣成長為優秀的軟件架構師？我想，一靠匠心，二靠悟心。架構設計并無標準答案，但我仍然希望把我這些年的所思所想分享給你，更希望這些內容能給你一些啟發。
