自学架构设计的一个好方法
架構設計，講起來，比較虛，不像算法和代碼。你寫了一段巧妙的代碼，編譯，運行，如果最終結果是正確的，那就是正確的。
但架構設計就不同了，你就算自己腦子YY了一個架構出來，好不好，有時候自己還真不好判斷，只有真正實施了，才能知道結果。
于是出現了一個尷尬的情況，想參與架構設計的同學需要先有架構的經驗，但架構經驗又要來自實際的項目，事情好像陷入了死循環，無法破局。
這里我給大家分享下，一個自學架構設計的方法：?看開源項目的源代碼
我從大學開始看開源項目的源代碼，看得比較多的是linux 內核的源碼，也看過mysql , C++ stl ,boost 庫等的源代碼。
我個人的感覺是，收益特別大，尤其是對于架構上的收益，這個方法是單純的看書和資料，所無法比擬的。
?
看源代碼帶來的實際收益
如果，你看懂了一個開源系統的源代碼，你會知道，這個開源系統的整體架構，實現的細節，一些精妙的設計之處，你都會接觸到。
這些東西會對自己產生潛移默化的影響，就像寫文章的人，要多看書一樣。時間長了，可以幫你形成一種架構設計的 “直覺”。
寫代碼是工程實踐，而架構師有時候更像一個藝術家，很依賴于架構師的經驗和直覺，多看優秀開源系統的代碼，更能直接地吸取這種經驗和培養這種直覺。
除了經驗和直覺上的積累，看源代碼還帶來另外一個直接的收益。
比如，你是做linux 服務器開發或維護的，如果你看過不少linux 內核的代碼，那你對 linux 里面很多具體的實現機制肯定是有深入了解的。
這部分的知識和經驗，絕對是你工作中強有力的武器，你在設計和維護服務器的時候，都可以做的比一般人更好，而且很快會成為團隊內的linux 專家，技術地位杠杠的。
同理，如果你做的是java 服務器的開發，你看過Java虛擬機的源代碼, 做出來的設計和寫出來的代碼，肯定會考慮到更多的實際情況，性能和穩定性都會更好，你同樣很快會成為團隊內部的虛擬機專家。
客戶端和前端的同學也一樣(android系統的實現機制，瀏覽器，V8引擎的實現機制等)。
那怎么來看源代碼會比較好呢，下面來說說
?
看之前先要搞清楚整體架構
看源代碼前，先要通過對應的書籍和文檔，搞清楚整體的系統架構，然后，再開始進入代碼。
是的，從源代碼里面是很難看出整體架構的，書和文檔容易的多。
如果你一開始就撲進代碼堆里，你很快就會感覺沮喪了，你會找不著北。
我一開始看源代碼的時候，也是一上來就撲到代碼堆里，看得云里霧里的，看得很吃力。甚至有時候，一個子系統的入口，都要找個半天，有時候出現兩個類似的，還不能確定是哪個。
后面，我發現很多比較知名的開源系統，除了有開源的代碼，還有不少的書籍和文檔。所以先通過書籍和文檔，盡量的搞懂系統的設計，再進入源代碼，會有事半功倍的效果。
比如，我去看ext4源代碼的時候， 我用盡google, 百度上的資源，先中中文的看起，看完看英文，當我確定，基本理解整個的設計，包括磁盤布局，數據結構，大體的數據流程，關鍵設計點后，我才會開始去看代碼。
因為我體會到，整體的架構，如果你看文檔的時候看不懂，你在看代碼的時候也是很難看懂的。
你或許會說，如果看書籍和文檔就搞懂了系統，那還看源代碼干嘛。
書籍和文檔能讓你對系統有個整體的認識，讓你知道，這個系統有那幾個部分，每個部分是怎么銜接的，給了你一個代碼的藍圖。
帶著這個藍圖，你看完代碼，才能真正知曉和體會到，系統設計的權衡和精妙之處，才不會有云里霧里的感覺。
如果你只看了書籍和文檔，那就像是有了一個藍圖，但沒有帶著這個藍圖去尋找寶藏，始終是空中樓閣。
?
看源代碼時，需要關注的點
看源代碼的時候， 從整體到細節的，你可以關注這些。
你可以關注，系統的整體設計，比如系統分了幾層，每層由幾個部分組。
你可以關注，層次之間數據的交互方式，最常見的當然是接口的方式，但也有的系統會采用隊列，共享內存等的方式。
你可以關注，各個模塊間接口的設計，包括接口的類型，接口的入口參數和輸出結果。
你可以關注，系統里面核心的數據結構，可以關注代碼層面的設計模式。
你可以關注，代碼里面，一些精巧設計的部分。比如 linux 內核里面，紅黑樹的實現，用C宏實現的泛型鏈表操作等，你會驚嘆還能這么玩。
你還可以關注異常處理流程等。
看源代碼其實是很有意思的事情，自己要帶著問題和思考去看，你會發現有一片新的天地，這個也是看代碼帶來的一大樂趣了。
?
學會 “囫圇吞棗”
剛開始，看一個系統的源代碼的時候，你會想要全部搞懂。
你一直地看，覺得終于看到一個函數的盡頭，最后一句的時候，突然出現一個新的入口函數，你點擊去，發現是”新大陸“，你崩潰了。
剛開始看源代碼的時候，經常遇到這種挫敗感，總感覺看不透，很多細節不懂，后來學會 “囫圇吞棗” 的方式，就消除了這種感覺。
看不懂的也不深究，跳過，看能看懂的。后面，來來回回地看，有時，隔了一段時間，剛好有接觸到，就再看，最后還是能看懂很多。
其實看源代碼不能抱著大而全的意識去看，而應該抱著，看懂一點是一點的意識去看，你會有完全不一樣的感覺。
你沒了那種 “大而全” 帶來的壓力，取而代之的是點滴收獲的累積，你看得過程也輕松了很多。
因為源代碼不是一般的教科書，你不需要“大而全”，能吸收多少，是多少。
?
新手和老手的區別
這里還是有些區別的，對于新手，建議是看完文檔后，一定要去看源代碼，要不就是 “隔靴撓癢”，最后收獲一定不大。
但如果是經驗豐富的老手，就要區分看待了。
比如一個實際參與過數據庫系統設計和實現的老手，在看mysql 的時候，很多部分，他可能看完文檔和書籍，心里就已經有各種具體實現甚至是實現細節了，這時候，他確實可以不用再去看源代碼。
當然，這個是基于，他已經有這部分豐富的實踐經驗的基礎上。
但對于沒有經驗的新手或經驗不足的同學，還是建議看源代碼的，要不就會有一種”飄“的感覺。
?
關于時間
看開源項目的源代碼，是挺花費時間的事情，所以這塊，也需要做比較好的安排。
如果你是學生，沒有太大的學習和項目壓力，你可以根據自己的興趣選擇喜歡的開源項目。
當然，盡量選擇知名的開源項目，因為知名的開源項目，它整體的設計，編碼等都是被實際生產環境驗證過的，是正真的好項目，就像看書要看好書一樣，看開源的代碼，也要看好的開源代碼。
如果你已經工作，時間不太充裕，那盡量選擇跟自己工作相關的開源項目。比如，你是做服務器開發的，你每天都要跟數據庫打交道，進行CRUD，那你可以考慮看mysql的書籍和mysql的源代碼。
一來，可以學習到mysql在這部分的架構和設計，積累經驗和培養“直覺“; 二來，所學到的這部分的知識可以直接的運用到工作之中。
比如，你在做SQL語句優化的時候，如果，你知曉，mysql內部的實現機制，那你做起優化來，肯定要順很多很多，說不定，不久之后，你就成為了，你們團隊的mysql專家了。?
如果時間比充裕，可以大塊，大塊的看。如果時間比較吃緊，就具體的某個部分，結合書籍和文檔來看。
?
結尾
對于項目經驗不是很豐富的同學來說，如果想在工作外的時間，積累架構經驗，培養架構“直覺”，結合書籍文檔，看開源系統的源代碼是個不錯的方法。
我看了不少開源系統的源代碼，確實收益頗多，很多的常用架構，設計模式，方法，實際實現的方式，都可以通過看開源系統的源代碼獲得，而且消除了只看書或文檔，帶來的云里霧里的感覺。
有興趣的同學不妨試試。
總結
以上是生活随笔為你收集整理的自学架构设计的一个好方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mongodb studio 3t 破解
- 下一篇： 技术生涯二三事(上)