沈劍老師在阿里雲的直播中分享的一些自己關於架構師的看法和成為架構師的心路歷程，內容經精煉整理成文，分集如下：
上篇：我的架構師之路
本篇：架構師“三部曲”
下篇：網友經典Q&A
直接觀看視頻
一、架構師，什麼樣的人適合？
好多同學會有類似“我適不適合”的問題，比如：走技術，還是走管理？走深度，還是走全棧？帶項目，還是帶業務？沈劍老師認為每個人的個人情況不同，這類問題沒有標準的答案，但是可以通過問自己一些問題來分析自己。自己不適合，主要需要考慮兩個方面：我喜歡什麼和我擅長什麼。
如果不知道自己擅長什麼，不知道自己想要什麼，可以問自己幾個問題：把它當做職業，還是事業？解決技術問題，還是解決業務問題的時候更有成就感？自己單幹，幫助團隊成果，哪一個更有成就感？這些問題是要自己想清楚的，別人能你方向和經驗，但是沒法給你答案。走技術，還是走管理？對於這個問題，可以想一下是在做技術的時候還是帶團隊成長更加興奮。走深度，還是走全棧？這個問題，可以想下是深挖一個技術細節更加興奮還是學習各種新技術更加興奮。帶項目，還是帶業務？這個問題考慮下是項目組按時交付更讓你興奮還是帶領一個業務完成各種考核指標更讓你興奮。做一件事情的時候，口頭禪是“我應該”、“我可以”還是“我想要”。他們的主要差別是在於主動去做和被動去做，“我應該”、“我可以”是相對被動的，而“我想要”是主動的。以上問題至少可以得出“我喜歡什麼”這個問題的答案。
找到“我喜歡什麼”這個問題的答案後，我們還要考慮“我擅長什麼”。所以還要一些問題，這些問題是幫助自己找到自己擅長的：問自己，擅長搞技術，還是帶團隊？問同事，問領導，對自己的哪些產出更滿意？看歷史，做項目帶業務，結果如何？上面有的問題是問自己的，有的是問其他人的，自我覺察可能沒有那麼準確，這時候可以問領導和同事，對自己的哪些產出更加滿意，過往的成績是不會騙人的。在找到自己擅長的過程中，心裡要有譜，我在做什麼的時候是容易的，壓力沒那麼大的。
圖1 架構師，什麼樣的人適合？
二、有什麼坑?
很多人會問走架構師這條路有什麼坑。比如，對於架構師來說，寫代碼還是不寫代碼？沈劍老師認為架構師是需要寫代碼的，且架構師要對業務非常瞭解，且業務中最核心、最關鍵的代碼最好是架構師來寫，且這個能力是一個架構師的核心競爭力。如果真的沒有時間來寫，也要Review這塊代碼，並且進行把關，否則很有可能不同部門之間會造成對業務邏輯的認知偏差。
另一個問題，寫PPT，還是不寫PPT？沈劍老師認為這個問題與寫不寫代碼的問題不矛盾，PPT是一定要寫的，這本身也是一種能力。抽象、總結、沉澱、傳承，本身就是一個架構師的核心職責之一。沈劍老師認為作為一個架構師，架構文檔寫不好，架構圖畫不好，不是一個合格的架構師。包括文檔也一樣，是對自己工作的總結，是對自己負責，也是對其他人的負責。寫代碼、寫材料、寫文檔都是一樣的，是不矛盾的，架構師都需要做，而這也是當前很多架構師需要進步的地方。
還有一個問題：單幹，還是帶團隊一起成長？沈劍老師認為，很多大型公司的代碼，是無法一個人寫的，一定是團隊在作戰。在大的公司，架構師是一定要帶團隊的。而且在很多公司，架構師和帶團隊也是沒法分開的，如果單幹的話很多複雜的系統是無法完成的。架構師在帶團隊一起成長的過程中也獲得成就感，對自己的成長也有幫助。
圖2 架構師必須要堅持的幾點
三、如何成為一名優秀的架構師？
要想成為一名優秀的架構師，首先會遇到的一個問題：使用最先進的技術，還是使用適合的技術？沈劍老師在文章中經常提到的一句話，架構不只是設計而來的，而是演進而來的。在做架構工作中要避免一個問題：不針對業務進行架構，比如突然接觸到一個高深的技術，腦子一熱就想要用到業務中。要知道架構是為了解決問題的，不是為了技術來架構，你學到的新的技術，有時候並不與業務相適應。一些架構師傾向於使用最前沿的技術，但是這些技術往往不是很穩定。對於新技術我們要去學習，要去關注，要去研究，但是與將其應用在線上是兩回事。新技術對於個人履歷來說是加分項目，但是新技術應用到線上要慎重，作為一個架構師要對整個業務負責，而不是單純的為了給自己的履歷加分就置業務於不顧。總的來說，學習新技術與應用到線上是兩回事，我們不能將兩者定性的聯繫起來，架構師為了自己的履歷而一心的去使用新技術，有可能會給運維、測試等部門帶來不必要的麻煩。
另外一個問題，做架構師是否需要聽產品的“嘮叨”？沈劍老師認為要多和產品去溝通，去問清楚為什麼要這麼做，這麼做技術的難度大不大等等，可以從架構的角度給產品一些反向建議，以優化產品的功能來達到優化架構的功能。比如說秒殺的例子，這種業務能否異步呢？比如說下單之後要在一定時間內付款，而不是需要立馬支付，這樣子把下單和支付分開，大大降低了併發，給架構的壓力也小了許多。
很多架構師在架構的過程中會出現較真的現象，試圖做完美的系統。沈劍老師認為我們要依據二八原則，解決主要矛盾為優先，因為人無完人，架構也沒有面面俱到的架構。如果為了一個出現概率千分之一的問題，使架構複雜了二十倍，那麼這個投入是不划算的，擁有太多的what if，系統就沒有做了，沒有完美的系統。比如拿58同城為例，現在的架構跟十年前的架構肯定是不同的，但是就算現在回頭再去設計十年前58同城的架構，仍然會是一樣的，架構是結合業務的，脫離了業務的架構設計，都是耍流氓。
圖3 如何成為一名優秀的架構師
更多精彩，點擊查看
上篇：我的架構師之路
下篇：網友經典Q&A
直接觀看視頻