代碼只要寫得多，就能成為頂尖的架構師？

作者 | 大飛

本文經授權轉自「大飛碼字」

同時期進入到同一間公司，參與同一個項目的同學，時間長了之後，有同學的架構能力很強，有的卻還像一個新手，造成這種差別的原因除了個體素質的差異，還有一個是工作方式和思考方式上的差異。

其實，在工作中，架構的學習和經驗的積累，是有一些比較好的方法的，這裡，我就來分享一下這方面的一些經驗。

項目，相比數量，規模更重

毫無疑問，在實際工作中，積极參与實際工程項目是快速積累經驗最好的辦法。

相對於項目的數量，項目的規模更加重要。我們沒辦法在一個項目開始的時候，去判斷一個項目的質量。但項目的規模是可以比較容易判斷的。實際服務用戶的數量，參與工程實施的各類人員的數量，都可以反應出項目規模的大小。

為什麼更應該追求項目的規模呢？因為項目的規模越大，可能遇到的各種架構問題就會越多，你能從中學到的東西自然也會越多。

一個億級用戶的項目比一個千萬級用戶的項目的複雜度，不是只高一倍的，項目的複雜度是成指數增長的。你在一個千萬級用戶項目中遇到的一個小問題，在億級用戶的項目中，卻有可能是最難解決的問題。

之所以說去大公司好，除了流程上更加規範，也因為用戶量更大，系統複雜度更高，個人也能得到更大的鍛煉。

當然，在實際工作的時候，你或許沒辦法選擇自己的項目，那就盡量做好手上的吧，一旦有機會，就積極地去爭取。

由點及面的了解系統

規模大的項目，可能不常有，而且人的時間和精力也是有限的，不可能參與無限多的項目。做每個小項目的時候，如果可以盡量多地汲取設計經驗，會成長的更快。

那怎麼來做呢？ 你需要學會由點及面的了解系統。

當你接到一個小需求，在一個已有的項目上面，增加一個小功能，比如就是資料庫的CRUD的操作。你可能覺得很無聊，沒啥技術含量，如果你這麼想，那你可能錯失了一個更好的理解系統，精進經驗的機會。

以前，我參與QQ系統後台項目的時候，剛開始接到的幾乎都是很小的需求，有一段時間，甚是無聊。後來，有一個前輩跟我聊，他說你要學會由點及面的去了解系統，半年之後，你對系統的理解程度肯定會更全面，深刻，後面有大需求的時候，你才有可能hold得住。

比如，我接到一個增加一條新的客戶端協議的需求。這個需求本身實現起來比較簡單，因為介面都是現成的，只需要按照規範去設計欄位，配置上去就可以了。如果是一般的做法，做到這個程度也就結束了。

但如果你採用由點及面的辦法，你應該去了解整個協議鏈路的設計，你會發現，為了保證協議的可靠性，系統做了很多額外的設計，這個才是系統設計真正有難度的地方。

我後面通過搜索和查找資料，還發現了業界通用的做法 --- XMPP協議。

當時我如果不深入的理解和挖掘這部分，估計到現在都不知道有這個協議。

發現這個協議，對我像是打開了一片新的天地，原來類似的系統設計和協議，早已經有一堆的人研究過，並給出了很好的解決方案。

時間長了，這種工作習慣，能給自己帶來很大的成長。很多同學問我，他每天在公司就是CRUD，感覺技術沒成長，那你確定自己深度的了解過你在CRUD的系統嗎？你有去深入的學習和擴展這部分嗎？

（CRUD是指在做計算處理時的增加(Create)、讀取查詢(Retrieve)、更新(Update)和刪除(Delete)幾個單詞的首字母簡寫。）

多思考，這個特別關鍵

如果只是簡單的實現業務功能，很多人都可以做到，根本不需要厲害的人, 那厲害的人是怎設計的？

除了功能需求，還需要考慮安全需求，性能需求，可靠性，穩定性等。這些才是系統設計的難點和關鍵點。

這些需求，是不會從產品經理的口裡提出的，這個是架構師的職責之一：從產品需求，業務需求裡面提出安全，性能，可靠性，穩定性等系統層面的需求。

一個產品經理不會跟你說，你的系統要保證安全，能抵受黑客的攻擊。他們默認，這些屬於技術的範疇，應該由技術來解決，當然，這也合理。(他們甚至不知道這些還要設計)

所以，一個合格的架構師，在接到這些產品，業務需求的時候，一定要能夠全面的思考，給出除了業務需求外的系統需求，並要求自己或其他同學要去設計和實現這些系統需求。

這是一種思維方式，也是做事的一種習慣。剛開始的時候，你可能沒有這種意識和習慣，但你要有意識的去培養它們。

這種思考，到後面可以形成一種架構設計的直覺。比如，我有時候會接到一些很重要的任務，我進行一輪思考和設計後，卻發現比預想的要簡單，這時候，我的直覺就會告訴我，我可能是遺漏了一個關鍵的部分。

或者是對需求的理解不充分，或者是對關聯繫統的了解有盲區。然後我都會重新review 一遍，很多時候，這種直覺，幫我避免了不少坑。

系統故障後的技術復盤

再穩定的系統，也會有故障。如果是業務高速發展中的系統，那故障的頻率應該就更高了。你們的團隊，有定期過故障的習慣嗎？

我們就經常做這類的事情。

一個故障發生後，肯定是先處理，然後安撫用戶，待一切處理完畢，我們通常會由系統的負責人，出一份故障報告。這份故障報告會詳細的記錄故障的處理過程，比如xxx時xx分，xxx做了什麼操作，然後還會詳細描述故障產生的原因和後續的改進措施。

這份故障報告寫完後，會以郵件的形式發給整個團隊，大家會一起來review 故障的處理過程和故障產生的原因。

我們會定期舉行故障復盤會議，大家會在一起討論問題的根本原因和改進的措施，更進一步的，會由點及面的延展開來，全局看待問題。

故障復盤會議，大概一個月執行一次。我們會拉上相關的負責人，一起來看這個月內發生的故障，分析故障的處理流程，分析設計和程序上的問題。

我們發現有的問題是設計的缺陷，有的問題是程序的bug，有的問題是已知問題，但因為成本或其他原因，所以暫不解決。這個過程使得團隊成員對系統越來越熟悉，研發流程也被規範的越來越好。

定期的技術復盤，幫我們發現了很多問題，還預防了不少問題的發生，我們從中也發現了很多系統設計上的缺陷。

對外的分享，總結，提升影響力

最後一點，項目整體完成後，要嘗試去總結和分享，會帶來很大的額外收益。

第一個收益。你可以總結自己做的這個項目，通常你都可以發現不少的問題和可改進的地方。這些存在的問題，你應該放到自己的腦子裡進行思考。我覺得一個優秀的架構師和一個普通的架構師的區別，很大部分是源自思考的廣度和思考的深度。

第二個收益來自於影響力，這個很多的同學都會有點不在乎，但這個影響力越到後面，就越顯的重要。影響力地積累需要比較長的時間，所以越早意識到這點，越早有意識地去分享和打造自身的影響力是特別重要的。

對外分享，可以是寫篇文章，可以是寫個ppt，給組裡，給整個項目團隊，或者給一些外部會議做分享，都可以慢慢地積累起這種影響力。

在很多的公司，技術影響力也是技術職級評定的一個關鍵直指標，所以相當的重要。

結語

以上，是我這麼些年來，架構設計方面的經驗積累。個人覺得架構設計能力的提升和經驗的積累，沒有特別的捷徑，但跟平時的工作習慣和思考意識有很大的關係。

有同學接到一個需求，做完就做完了，其它的也不理會，長久下來，肯定是沒什麼成長的。如果你想成為一個優秀的架構師，就需要培養這種做事的方式和思考的習慣。

作者：大飛。十年互聯網人，資深架構師，技術leader。

聲明：版權歸作者所有，如需轉載請聯繫原作者。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！