我翻看了我的歷史文章，寫了不少技術相關的東西，但發竟然沒有架構設計方面的文章。所以今天就來聊聊這塊。
寫這篇文章前，我仔細想了一遍，架構設計這麼重要的東西，我怎麼會一篇都沒有寫呢。後來我想，可能是我這麼多年的工作裡面，幾乎沒有參加過什麼架構學習或架構培訓等方面的事情。同事間也極少提起過所謂的架構學習等類似的事情。 我參加過不少分享系統設計經驗方面的會議。但這種跟一般意義上的學習很不一樣。更多是在看別人做系統的時候，是怎麼想的，那個特定的場景，會有哪些坑，更多是經驗的分享。 所以，可能也是這方面的原因，導致在我的潛意識裡面，不存在架構學習的概念。架構能力更多是來自實踐和經驗。
能力本身由知識加經驗融合而來。知識可以通過書本，課程等的學習習得。經驗則要通過實踐才能獲得。**能力，演算法能力都是如此。需要邊學習知識，邊動手實踐。相對於**能力和演算法能力，架構能力更加偏經驗化。**和演算法能力，可以通過邊看書，邊做習題的方式提高。而且十分有效。 但架構能力用這種方式、卻難有效果。究其原因，我覺得是這樣的。
相對於架構設計，**和演算法邏輯上更加嚴密，而且容易驗證學習效果。你在學習乙個**特性和一種新的演算法思想的時候，你可以先看書，在理解完相應的知識點後，就可以通過自己寫**或做題，來驗證自己是否掌握了這部分。這種驗證是確定的，只要你的**能跑通，結果符合預期，你幾乎就掌握了這部分。但架構設計卻不太行。 一來架構設計的很多原則都是經驗性原則。比如高內聚低耦合，比如依賴倒置原則，都很經驗性。怎麼樣的內聚程度叫做高，怎麼樣的耦合叫做低，不同的人的理解也不一樣。沒有統一標準的辦法去判斷。所以就算你理解了這種設計思路，但你也沒辦法驗證你是否真的掌握。 當然，你可以實踐，但架構設計的實踐門檻是很高的。 如果你只有乙個人，你至少要做個耗時幾個月規模的專案，你才能從中體會到設計原則的一些好處。而且這種個人專案，所積累的經驗，在多人專案中還不一定適用。 因為架構設計的重要目標，就是為了解決多人協同開發的問題。 所以要積累這塊的經驗，就必須要去公司了。 基於這種原因，就導致架構能力很難，甚至沒辦法像**和演算法那樣去學習。
乙個人架構能力的高低，除了努力和天賦，還有乙個很關鍵的點，是他歷史上曾經參與設計實踐的系統規模的大小。
因為架構能力，具有規模向下相容性，向上卻不行。
以網際網路行業來說，曾經參與設計實踐乙個面向億級使用者系統的架構師，再去設計乙個面向千萬級使用者的系統，是可以完美勝任的。但反過來，卻不行。 無論是前端，客戶端，後台都是一樣。 例如客戶端，在面向千萬級使用者的客戶端裡面，偶爾出現，不影響整體的問題，當使用者規模到達乙個億後，至少會成10倍的放大，當各種問題同時出現，可能會引發更大的崩潰。這時候就需要去解決千萬級別沒有遇到的問題。所以面向億級的設計要比面向千萬級的設計難很多。 但反過來，就容易的多，乙個擁有過億級使用者系統設計經驗的架構師，在設計乙個千萬級系統的時候，所面對的問題，在億級的時候都是面對過的，需要做的就是不要過度設計。具體做的時候，有點像是在億級系統設計方案上進行裁剪。當然有經驗的架構師可能很容易判斷哪些點需要，哪些點不需要。在設計之初，他就已經想好了，所你看不到這麼個過程。 因此也可以看到，在大公司經歷過大規模系統設計實踐的架構師會相當搶手，因為架構設計能力是可以向下相容的。
所以我個人覺得，因為**和演算法能力的實踐門檻低，這方面厲害的人，靠的是天賦和自身的努力。 而架構設計能力，除了自身的天賦和努力外，還要外加一些運氣。 如果在你的職業生涯裡面，沒有遇到好的規模大的專案，你就沒辦法進行這塊的實踐，自然也沒辦法擁有這方面的經驗能力。
以上，是個人對架構能力的一些想法。可能不同的人，有不同的理解吧。不過架構能力確實是高階技術人員很核心的競爭力。想在技術領域有長遠發展的同學，一定要關注這塊。 最後，這篇沒有介紹架構能力提公升等方面的內容，後面找個時間再來寫寫這塊的內容。
我對架構設計的理解
遊戲架構設計是乙個老生長談的話題，以前給多個遊戲公司培訓過，隨著時間的積累，對遊戲架構設計的理解又多了一些，在此給讀者分享一下我對於架構設計的理解。遊戲架構設計是基於引擎的基礎上的二次封裝，目的是便於遊戲開發者能夠專注於邏輯的編寫，便於多人協同開發，便於功能的擴充套件等等。不論使用什麼引擎，只要掌握...
提公升架構能力
摘自 easy dry是don t repeat yourself的縮寫，翻譯過來就是 不做重複事 這正是 個逼近軟體本質的原則，它指導我們把經常使 的功能抽象成庫，把重複出現的 重構為可重 的框架模組。如果你 dry來要求 很快你就會發現 抽象和架構能 的飆公升。半自動化 但是我們活在現實世界，所...
我對三層架構的理解
三層介紹及其的職責 層之間的關係以及規則 三層架構的優缺點總結 概念 資料訪問層 dal 主要負責對資料庫的直接訪問，向上層遮蔽資料庫差異。關係 規則優點 降低維護成本，方便管理。對於不斷變化的系統有著先天的優勢。遮蔽資料庫差異。適合大型專案及合作開發。安全性。缺點執行速度。量大。層次的劃分並不是死...