1架構師平時都做些什麼事？

主要當然是跟架構相關的事情吧（好像是廢話哎），具體一點就是架構設計，講解推廣，然後再做一些程式碼方面的工作。說起來，講解推廣可能是很多人不太重視的，但其實它的比重還是比較大的，基本能到三成。

而這三者的比例，5：3：2也是很經常的。也就是說，團隊到達一定的規模，架構師可能80%的時間都不在程式設計而在思考上。想（設計）不好，團隊就會走很多彎路。很多時候我們太忙，看起來是事情太多，但其實可能是想得太少。

會寫程式碼麼？會寫，但是可能並不會是核心程式碼，這個其實看每個團隊的成熟程度，比如早期我會寫一些核心程式碼，但是後來因為團隊比較厲害了，如果我不分配足夠的精力在某個功能實現上，為了不拖累整體的進度，會傾向於寫一些邊緣的程式碼，主要是瞭解團隊的程式碼質量和實現進度。現在可能更多的寫一些試驗性的程式碼，去玩一些新的技術。

這裡面還有個很特殊也很重要的工作，就是故障處理。對於一個系統來說，實現出來只是第一步，真正做成高可用的系統，還有相當長的路要走。這個過程中，你會遇到各種各樣的情況，遭遇系統宕機、服務崩潰等等。基於故障的改進是架構演化很重要的一種形式。我們經常說，故障是推動技術進步的重要動力，就是這個意思。在處理故障的過程中，才會更容易體會思考當前系統的缺陷，後續改進的方向也會更加明確清晰。

前面這些事情基本都是屬於輸出型的，是個人對團隊的貢獻。個人層面，我還是需要不斷地輸入，學習新的知識，保持對行業、領域內新技術的更新。這裡也向大家推薦一下，看論文可以認為是架構修煉的一個捷徑，因為很多論文寫得比較嚴謹，也會比較系統，瞭解一個系統實現的細節甚至是思想都很方便。

再有點時間，可能就是寫寫文章，最近（一年前）寫了一個公眾號，大家有興趣可以關注，名字是「一樂來了」，不過可能還是年更 :P

2分享走過的坑，如何做架構？

我第一反應感覺自己沒走過多少坑，但是後來想想，其實這也許是在坑裡的表現，因為一般在坑裡的人是不知道自己在裡面的。

話說回來，我覺得有一個坑是所有工作的人都很容易遇到的，就是要認識到研發類工作遇到的問題，在很多情況下，不僅僅是技術問題，這就意味著並不是解決了技術部分就能解決掉的。

拿我自己舉例。剛開始做系統設計的時候，有一些架構改造的點子經常不被認可，跟同事跟領導說起來，大家雖然沒有什麼意見，卻應者寥寥。當時有一種強烈懷才不遇的感覺，甚至一度對團隊都產生了懷疑，非常苦惱。

後來忽然有一天想明白了，只要還在一個團隊，還是得做些事情說服別人才有意義，保持清高卻期待變化是不現實的。想說服大家還是得換個角度，先去思考別人為什麼不接受。順著這個方向，慢慢解開了這個結。一般這種你覺得自己不被人理解的情況，基本都是你因為對技術的興奮，過低評估了風險，或者沒有考慮人的因素（是否充足，投入產出比），或者沒有考慮專案的因素（排期進度方面）。

多說一句投入產出比的事情。其實單純的技術改進很多情況下都沒有太大價值，除了個人能練練手以外。技術真正發揮價值的地方，一定是在對使用者產生影響的時候。如果做不到這點，一遇到人力緊張的情況這樣的技術改造就會被放棄。當然說起來應該也算好事。

至於如何做架構呢？我推薦一個工具iPad Pro，也給大家演示一下像Paper53、Notability這樣的應用。這些都是我在平時給大家講解時會用到的，比單純的PPT要好很多。因為從一個架構圖開始，給大家建立整體的概念，然後細化分析其中的元件，在這個過程中再不斷提醒這個元件在整個系統中的位置，對於理解一個系統來講幫助是非常顯著的。

服務從本質上來講就是資料的處理，而架構設計就是在定義資料流轉方式而已。

3對想做架構師的同學的幾點建議？

最重要的當然是要像架構師一樣思考。今天來看直播的有很多不同階段的同學，我再說一些稍微具體的建議，當然也結合我看到的很多人容易走進的誤區。

對於剛入門的同學，在聽到一些新的熱的技術時，一定不要只是看熱鬧，要去看門道。很多人都可以針對架構問題誇誇其談，但其實對概念並沒有瞭解清楚，表現出來就是好一點也只是知道某個東西是什麼，卻不知道它的優缺點，也不清楚為什麼在一些情況下要用。

慢慢的，當開始懂一些的時候，要找機會開始實踐。讀再多的文章，不如自己上手實現一次。這種實踐不是說完成一個專案就行，而是那些有挑戰的專案，因為架構問題只有在解決複雜問題的時候才會出現。說起來我們前幾天搞過一次PCC效能挑戰賽，目的也是這樣。

實踐之後，還要記得歸納總結。因為如果要實現一個系統，大多數人都會因為急於編碼而疏於思考。通過歸納總結，可以反思遇到的問題，重新思考系統的設計缺陷，不僅有助於以後做同類系統時不再踩坑，也因為沒有了實現系統的干擾壓力，更有可能舉一反三，發現更巧妙的系統設計。

最後對於有一定經驗的同學的建議就是，要多到社群交流。這不止是個學習的問題，而是對於一般人來講，到了這個階段很容易驕傲甚至自滿。這是一個很不好的情況，不僅自己不會再有提高，跟團隊的配合都可能出現問題。但你很難避免，部分也是因為人性使然。但是與人交流，特別是參加頂級會議，你會遇到很多跟你一樣優秀的人，甚至比你優秀更多的人。你跟他們交流，自然會發現技術領域的廣闊無邊，也就不會再有那樣的情緒了。

4程式設計師在35歲之後如何規劃？

提出這個問題，還是因為某大廠特殊對待35歲以上員工的新聞。我必須宣告的是我還不到35歲，所以並不能有35歲以上學習發展的經驗。

我們有時候確實會在意年齡，你10歲沒上小學，大家都說你晚了，你30歲還沒有結婚，你就是晚婚了。但是在這學習發展的方面，年齡其實並不是問題，規劃才是問題。

前幾天聊到人生髮財靠康波，說的是經濟週期都比較長，規律可能在長波維度（六十年左右）才能看出來。但是考慮到行業發展速度和人生長度，個人規劃還是比較適合短週期，比如我就一直在用五年規劃。

如果有規劃，一方面你可以有條不紊腳踏實地的在某一方面深耕，另一方面，也會幫助你儘早去掉一些沒有用的煩惱。

書單就是一個很好的例子。很多人都喜歡跟別人要書單，自己也會買很多書「準備」看。注意是準備，因為大多數人並不會真正看完。我之前在微博上分享過一個自己09年的閱讀相關的規劃，當時我把自己要看的書，按照書的厚度和每天要看多少來進行分析，當時的幾本書看完就要三百多天。也就是說一年不買書都看不完，而它們僅僅是案頭的一部分。這也是我現在並不會給人推薦書單的原因，如果一個人沒有規劃，書單只是一個購物單而已。

但是如果你開始規劃，你就會知道自己拼了命也只會看幾本書的時候，你就更容易理智對待要看的書，把精力分配到更值得看的書上，而不是撒胡椒麵式的隨意閱讀。值得精讀又能做到精讀的書還是有限的。

當然也一定要警惕，不要被你的思想所侷限。之前我寫過一篇文章「做業務系統也可以成為架構師」提過這個事情。人永遠不知道自己不知道的東西，規劃的時候也不能閉門造車，多找人尋些建議，看看別人眼裡的一些事情。

5程式碼之外，都在玩什麼？

介紹裡跟大家說過一句，業餘時間玩得還比較多。跑步、遊（喝）泳（水）、登（爬）山、足球（也是跑步）、騎馬（去年只玩了兩次），最近拳擊也開始玩了。

這些都很有意思，大家可以一起玩玩。但我覺得最值得推薦的，還是跑步。原因就在於程式設計師因為加班多，很容易得職業病。我個人曾經有嚴重的肩頸勞損問題，嚴重到每天工作九小時之後肯定會頭疼，因為肌肉勞損影響了頭部的血液迴圈。西醫看不出問題來，中醫鍼灸、艾灸、中藥、按摩也是多管齊下也不管用，直到後來開始跑步，才解決了這個問題。（一秒化身傳銷了）

現在我每次基本都跑一萬米。很多沒跑步的人都覺得難，其實是很簡單的事情，正常人不是可以過早放棄的話，都可以做到。我自己原來也不行，大學時候12分鐘跑都跑不下來，但這其實是一個健康人很容易達到的程度，只要你堅持練習就行。當然運動到了這個量級，確實也會對身體產生不小的負荷，也很容易有運動損傷，要注意技巧方法的改進，裝備該換就得換。

其他的就不多說了，有機會可以詳細聊。最後祝大家都能有個運動的愛好，養成這樣對人生有益的好習慣，畢竟好身體才是享受工作生活的基礎。

作者：一樂

文章來源微信公眾號：Infoq