我翻看了我的歷史文章，寫了不少技術相關的東西，但發竟然沒有架構設計方面的文章。所以今天就來聊聊這塊。

寫這篇文章前，我仔細想了一遍，架構設計這么重要的東西，我怎么會一篇都沒有寫呢。后來我想，可能是我這么多年的工作里面，幾乎沒有參加過什么架構學習或架構培訓等方面的事情。同事間也極少提起過所謂的架構學習等類似的事情。 我參加過不少分享系統設計經驗方面的會議。但這種跟一般意義上的學習很不一樣。更多是在看別人做系統的時候，是怎么想的，那個特定的場景，會有哪些坑，更多是經驗的分享。 所以，可能也是這方面的原因，導致在我的潛意識里面，不存在架構學習的概念。架構能力更多是來自實踐和經驗。

能力本身由知識加經驗融合而來。知識可以通過書本，課程等的學習習得。經驗則要通過實踐才能獲得。代碼能力，算法能力都是如此。需要邊學習知識，邊動手實踐。相對于代碼能力和算法能力，架構能力更加偏經驗化。代碼和算法能力，可以通過邊看書，邊做習題的方式提高。而且十分有效。 但架構能力用這種方式、卻難有效果。究其原因，我覺得是這樣的。

相對于架構設計，代碼和算法邏輯上更加嚴密，而且容易驗證學習效果。你在學習一個代碼特性和一種新的算法思想的時候，你可以先看書，在理解完相應的知識點后，就可以通過自己寫代碼或做題，來驗證自己是否掌握了這部分。這種驗證是確定的，只要你的代碼能跑通，結果符合預期，你幾乎就掌握了這部分。但架構設計卻不太行。 一來架構設計的很多原則都是經驗性原則。比如高內聚低耦合，比如依賴倒置原則，都很經驗性。怎么樣的內聚程度叫做高，怎么樣的耦合叫做低，不同的人的理解也不一樣。沒有統一標準的辦法去判斷。所以就算你理解了這種設計思路，但你也沒辦法驗證你是否真的掌握。 當然，你可以實踐，但架構設計的實踐門檻是很高的。 如果你只有一個人，你至少要做個耗時幾個月規模的項目，你才能從中體會到設計原則的一些好處。而且這種個人項目，所積累的經驗，在多人項目中還不一定適用。 因為架構設計的重要目標，就是為了解決多人協同開發的問題。 所以要積累這塊的經驗，就必須要去公司了。 基于這種原因，就導致架構能力很難，甚至沒辦法像代碼和算法那樣去學習。?

一個人架構能力的高低，除了努力和天賦，還有一個很關鍵的點，是他歷史上曾經參與設計實踐的系統規模的大小。

因為架構能力，具有規模向下兼容性，向上卻不行。

以互聯網行業來說，曾經參與設計實踐一個面向億級用戶系統的架構師，再去設計一個面向千萬級用戶的系統，是可以完美勝任的。但反過來，卻不行。 無論是前端，客戶端，后臺都是一樣。 例如客戶端，在面向千萬級用戶的客戶端里面，偶爾出現，不影響整體的問題，當用戶規模到達一個億后，至少會成10倍的放大，當各種問題同時出現，可能會引發更大的崩潰。這時候就需要去解決千萬級別沒有遇到的問題。所以面向億級的設計要比面向千萬級的設計難很多。 但反過來，就容易的多，一個擁有過億級用戶系統設計經驗的架構師，在設計一個千萬級系統的時候，所面對的問題，在億級的時候都是面對過的，需要做的就是不要過度設計。具體做的時候，有點像是在億級系統設計方案上進行裁剪。當然有經驗的架構師可能很容易判斷哪些點需要，哪些點不需要。在設計之初，他就已經想好了，所你看不到這么個過程。 因此也可以看到，在大公司經歷過大規模系統設計實踐的架構師會相當搶手，因為架構設計能力是可以向下兼容的。

所以我個人覺得，因為代碼和算法能力的實踐門檻低，這方面厲害的人，靠的是天賦和自身的努力。 而架構設計能力，除了自身的天賦和努力外，還要外加一些運氣。 如果在你的職業生涯里面，沒有遇到好的規模大的項目，你就沒辦法進行這塊的實踐，自然也沒辦法擁有這方面的經驗能力。

以上，是個人對架構能力的一些想法。可能不同的人，有不同的理解吧。不過架構能力確實是高階技術人員很核心的競爭力。想在技術領域有長遠發展的同學，一定要關注這塊。 最后，這篇沒有介紹架構能力提升等方面的內容，后面找個時間再來寫寫這塊的內容。

總結

以上是生活随笔為你收集整理的我理解的架构能力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。