程序員干多久才能成為架構師，代碼只要寫得多，就能成為頂尖的架構師？

作者 | 大飛

本文經授權轉自“大飛碼字”

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

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

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

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

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

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

一個億級用戶的項目比一個千萬級用戶的項目的復雜度，不是只高一倍的，項目的復雜度是成指數增長的。你在一個千萬級用戶項目中遇到的一個小問題，在億級用戶的項目中，卻有可能是最難解決的問題。程序員架構師主要是做什么？

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

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

由點及面的了解系統

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

那怎么來做呢？?你需要學會由點及面的了解系統。程序員架構師，

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

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

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

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

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

當時我如果不深入的理解和挖掘這部分，估計到現在都不知道有這個協議。架構師和程序員的區別，

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

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

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

多思考，這個特別關鍵

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

除了功能需求，還需要考慮安全需求，性能需求，可靠性，穩定性等。這些才是系統設計的難點和關鍵點。程序架構師很厲害嗎。

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

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

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

這是一種思維方式，也是做事的一種習慣。程序員幾年能夠成為架構師、剛開始的時候，你可能沒有這種意識和習慣，但你要有意識的去培養它們。

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

或者是對需求的理解不充分，或者是對關聯系統的了解有盲區。然后我都會重新review?一遍，很多時候，這種直覺，幫我避免了不少坑。程序架構師是做什么的？

系統故障后的技術復盤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結語

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

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

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

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

【End】

?曾斷崖式跌落的三星，能否在中國東山再起？

?前端開發這么多年，你真的了解瀏覽器頁面渲染機制嗎？?|?技術頭條

?fork()成為負擔，需要淘汰 | 極客頭條

?程序員 996 再上熱搜，黑名單增至?84?家！

?與云原生及開源大神們的第二次親密接觸 | 全議程重磅發布

?V神玩起freestyle!?5位以太坊核心大咖在悉尼的演講精華全在這了！|?直擊EDCON

?“重構”黑洞：26歲MIT研究生的新算法?|?人物志

?程序員為什么都愛穿沖鋒衣？（最全總結）

System.out.println("點個在看吧！");
console.log("點個在看吧！");
print("點個在看吧！");
printf("點個在看吧！\n");
cout?<<?"點個在看吧！"?<<?endl;
Console.WriteLine("點個在看吧！");
Response.Write("點個在看吧！");
alert("點個在看吧！")
echo "點個在看吧！"

點擊閱讀原文，輸入關鍵詞，即可搜索您想要的?CSDN?文章。