作者｜顧偉
編輯｜Alice Qin
6年修成架構師， 需要哪些職場軟技能？
我是誰？
大家好， 我是顧偉， 普元資訊的主任架構師， 也是個不折不扣的程式師型架構師。
這些年我一直在做產品研發相關的工作， 參與研發的產品方向也比較多， 從傳統的開發平臺、服務匯流排、應用伺服器， 到這些年的IaaS、PaaS、CaaS、DevOps等；技術方向也比較雜， 從一開始的純前端， 到J2EE， 到外掛程式開發， 再到openstack， cloudfoundry， docker， k8s等。
每個人都會有一個或多個飛速發展的階段， 這些階段自己可以感受到， 也可能從別人那邊感受出來， 不敢說是從0到1的那種質變， 但必須說這就是技術人的階段性升級。 今天的分享正是結合我這些年的經驗和總結， 來和大家一起看看作為架構師， 應該有哪些認知、以及必須掌握的軟技能。
換維思考， 每次挫折都是你的機會
每個人的職業生涯都有很多挫折， 有人被挫折打倒， 有人千辛萬苦地爬了出來，
墨菲定律
墨菲定律說的是：只要一件事情存在不同選擇， 那肯定會有人選擇不好的方式， 從而導致失敗。 挫折很多時候其實就是因為這個原因而產生。
對於我們這些技術人， 尤其是架構師來說， 面臨的選擇會更多， 如何做正確的選擇， 這是想成為合格架構師不可繞過的一道坎。 所謂的條條大路通羅馬， 在這裡反而是不合適的。
選擇是有理有據的拍板， 要做正確選擇， 必須要在這個行業、這個領域有足夠的積累。 自然又回到做什麼事都離不開的：知識的積累。 所以建議想做架構師的同學， 要選定行業沉下來去做， 一味的跳來跳去， 很容易造成領域的不夠深入， 最終適得其反。
重複的錯誤要引起高度重視
在職業生涯初期， 我遇到了一個非常好的專案， 給華為定制一款中介軟體平臺， 華為的嚴格程度， 只要大家合作過， 肯定都清楚的， 當時我就犯了一個錯誤， 而且是兩次。 如果沒有前面的鋪墊， 這個錯誤說出來我估計很多人都不以為然：某個圖示少了一個圖元。 在第一次他們提出這個問題時， 我真是不以為然的， 替換後就重新打版本了， 結果不久再次出現了這種問題， 當再次被當面提出時， 我覺得真的挺難堪的。
在這件事情後， 我對自己交付東西有了非常嚴格的要求， 即使一些代碼、素材不是我提供的， 我也會有意識的去驗證， 畢竟我參與了最終交付。 這個項目總代碼在50W左右，
要學會利用好每次失敗的機會
玩網游的同學都清楚， 打怪練級拿經驗、獲裝備。 而每一次挫折， 都是一個難得的提升經驗值的機會， 職業生涯要是都很順， 那要麼你真的足夠天才， 要麼你真的足夠運氣。
凡事都有兩面性。 再說的直白些， 關乎實際利益， 前些天有同學在談彼得定律， 彼得定律是一個“向上爬”定律， 人都是應該接受挑戰， 直到不能勝任。 如果你是一個領導或決策者， 一般你會給什麼樣的人機會， 所有人都會喜歡能承擔責任， 快速解決問題， 不斷優化的人， 但問題、瓶頸不是你說有就有的，
人都有認知慣性， 但架構師要脫離慣性
黑天鵝事件
黑天鵝事件告訴我們， 絕對的經驗主義， 在一些小概率事件發生之後往往會造成不可預估的風險。 這個事件用在IT系統上有時更準確， 像支付寶電纜被挖、樂視受攻擊、三星手機炸了等， 當然支付寶、樂視的應對能力都足夠出色， 說明其架構設計足夠優秀， 但給我們這些架構師的警示是：架構設計不能只考慮簡單的上下游以及資料驅動方式， 往往這些邊界事件、小概率事件更應值得重視。
業務變化驅動認知升級
我在做DevOps平臺， 這和我以前做的很多中介軟體不太一樣， 我就會發現我的很多認知放到這個平臺中是不完善的。 大家都知道，DevOps平臺重點是在既有的流程約束下，打通工具鏈、優化流程、實現精益。這個平臺既會覆蓋管理域，比如專案管理、產品管理，也會覆蓋開發測試域，比如敏捷開發、自動化測試、代碼庫管理，還會覆蓋運維域，比如自動化部署、多級監控、故障處理等。
大家可以去仔細觀察下，這些不同領域的工程師的思維方式、做事方法是有很大區別的，像我之前對於產品和專案管理域的認知就不夠，使得平臺中對於像需求基線、工作項、過程範本這些設計就容易出問題，所以說，架構師要隨著所涉及業務的變化持續學習，提升認知，不能老在自己的眼界範圍裡做事情。
在可控範圍中鼓勵創新
這兩天百度無人駕駛事件鬧得沸沸揚揚，究其原因就是逾越了一些底線。一個架構師如果設計了一個自己都無法cover的系統，後果難以想像，這也是設計的底線。最近在做DevOps、容器雲、微服務，很多人喜歡問我用了哪些開源技術，我說用了k8s、flannel、springboot、react、Jenkins、nexus、influxdb等，那馬上就會有人問有沒有試過mesos、springcloud、Prometheus等等。那我會說：其實真的挺想用的，但現在也是真的還cover不住，怕引起技術債還不起。
當然，也不要走到另一個極端，做成技術宅。逐步創新才是架構師的附加價值所在，總吃老本，很快還是會被淘汰，除非你已經是行業的風向標。
架構有方法論，關鍵是如何運籌帷幄
架構的本質是打造骨架結構
架構這個詞最早出自建築，其在建築行業中的重要性不言而喻。但來到軟體行業，很多人會覺得重要性沒那麼顯著了，甚至對架構師這個職稱的必要性都有所懷疑。其實出現這個疑問不難理解，因為現在很多架構師已經不再是做技術、業務架構相關的事情了，更偏向於管理協調、團隊組織這些事情，其實包括前段時間一直爭吵的CTO該不該寫代碼，也是個類似問題：某個職稱的本職工作是什麼？
架構師本質上還是要為系統建立鋼混架構，概念模型、資料模型、系統上下游、技術棧、部署設計、MVP，這些都是架構師的職責。尤其是資料模型和MVP，這是很多架構師不太去做的，但卻是鋼混架構中的鋼筋水泥，奠定了下限，也註定了上限。
方法論都是特定場景下的沉澱
做架構設計的方法也不少，關鍵是活學活用，比如4+1，比如togaf，還有DDD，ADMEMS這些。但是無論哪個方法論，都是有其特定的上下文場景的，跳出這個場景，也許就不如其他的合適了，比如DDD，非常適合有著複雜的分層架構與職責劃分，對於複用性要求也很高的系統設計，如果只是簡單的CRUD，那DDD反而不合適了。
所以切勿硬搬方法論，就像以前我們會習慣性的硬搬設計模式一樣，多總結，找到適合自己、適合團隊、適合平臺的一套方法來做設計，同時切勿把架構設計純粹做成設計，空談誤國，如何落地才是最重要的，這是架構師在方法論的基礎上最需要注意的。
還有一些講架構的書籍，其實大家也可以多關注，比如《架構之美》，《架構即未來》，《微服務設計》，《領域驅動設計》。
除了方法論，還有一些好方式
讀代碼是個很好的習慣，這10年中，我認為對我架構思路幫助最大的代碼有兩塊，一個是eclipse的源碼，eclipse將extension和extension point用到了極致，有著極強的延伸性考慮。另一個是cloudfoundry的源碼，雖然最終沒有用到產品中，但其在集成維度的抽象考慮，讓我受益很多。現在很多同學還會看openstack、docker的源碼，都是很好的框架，只是受語言能力限制，現在我們團隊還處在怎麼用精的階段。
做驗證也是一個好習慣，互聯網開源技術很多，不可能所有的你都有機會在專案或產品中用到，但很多技術在使用中會給你很多新的思考。記得之前用Hubot和Slack、WeChat做對接玩，我忽然就理解了一些應用生態的建立模式。所以在閒暇之餘，多用一用這些著名的框架，哪怕只是自己玩玩，對自己的認知也是很有幫助的。
勿忘初心，在變與不變中認清自己
還記不記得，10年前你為了什麼奮鬥？
一些新來的團隊成員喜歡問我，在一家公司呆10年是什麼感受，尤其還是從畢業開始。其實這個我也沒有很好的答案，比起很多我的一些朋友和同行，突然就跳到一些大互聯網或創業公司，甚至有做到了CTO，當然也有羡慕，但羡慕之餘，我自認為有兩個點，會使我更沉下心來向前走：
確實我還遠沒到那個水準，現在的崗位已經讓我隱約感受到了彼得定律所到的那層壓力
這一路以來，我是能不斷感受到自己在提升的，而這正是我10年前就在追求的。何況現在的我還處在了一個非常出色的團隊中。
現在的你適合做什麼？
有人說，到了一定階段，你在與不在，對於團隊、公司就顯得沒有那麼重要了。誠然，我也會覺得我現在的角色和能力，早已有團隊成員可替代，所謂的很多公司的高層變動，看似天要塌下來，事實上什麼也沒發生，像阿裡的、丁香園的、中國聯通的、包括像錘子的這些高層變動，大家也都看到了，人家照樣經營的很好。
所以在特定團隊中尋找自己的價值，讓自己過的不“心虛”，是我一直的動力。止於至善，細節決定成敗，永遠把自己看成是最後一班崗，這是我的原則，也是很多公司追求的freedom和responsibility的基礎。至於到底最適合幹什麼，只有努力去做了，才能知道。
直播預告
「 StuQ 公開課 」聯合知乎 Live ，為程式師策劃圍繞熱點技術、實戰案例、職場軟技能培養、職業成長規劃等涵蓋多技術領域技術內容的主題 Live。3月 30 日晚八點半，阿裡巴巴技術專家, 《 React Native 入門與實戰》作者——王利華，將為你帶來「三年從前端小工到架構」。本次分享從一個需求的開始到結束，深挖各個環節，從中發現可以提高效率的方面來解決這些難題，並養成良好的開發習慣。
戳「 閱讀原文 」直通Live。
大家都知道，DevOps平臺重點是在既有的流程約束下，打通工具鏈、優化流程、實現精益。這個平臺既會覆蓋管理域，比如專案管理、產品管理，也會覆蓋開發測試域，比如敏捷開發、自動化測試、代碼庫管理，還會覆蓋運維域，比如自動化部署、多級監控、故障處理等。大家可以去仔細觀察下，這些不同領域的工程師的思維方式、做事方法是有很大區別的，像我之前對於產品和專案管理域的認知就不夠，使得平臺中對於像需求基線、工作項、過程範本這些設計就容易出問題，所以說，架構師要隨著所涉及業務的變化持續學習，提升認知，不能老在自己的眼界範圍裡做事情。
在可控範圍中鼓勵創新
這兩天百度無人駕駛事件鬧得沸沸揚揚，究其原因就是逾越了一些底線。一個架構師如果設計了一個自己都無法cover的系統，後果難以想像，這也是設計的底線。最近在做DevOps、容器雲、微服務，很多人喜歡問我用了哪些開源技術，我說用了k8s、flannel、springboot、react、Jenkins、nexus、influxdb等，那馬上就會有人問有沒有試過mesos、springcloud、Prometheus等等。那我會說：其實真的挺想用的，但現在也是真的還cover不住，怕引起技術債還不起。
當然，也不要走到另一個極端，做成技術宅。逐步創新才是架構師的附加價值所在，總吃老本，很快還是會被淘汰，除非你已經是行業的風向標。
架構有方法論，關鍵是如何運籌帷幄
架構的本質是打造骨架結構
架構這個詞最早出自建築，其在建築行業中的重要性不言而喻。但來到軟體行業，很多人會覺得重要性沒那麼顯著了，甚至對架構師這個職稱的必要性都有所懷疑。其實出現這個疑問不難理解，因為現在很多架構師已經不再是做技術、業務架構相關的事情了，更偏向於管理協調、團隊組織這些事情，其實包括前段時間一直爭吵的CTO該不該寫代碼，也是個類似問題：某個職稱的本職工作是什麼？
架構師本質上還是要為系統建立鋼混架構，概念模型、資料模型、系統上下游、技術棧、部署設計、MVP，這些都是架構師的職責。尤其是資料模型和MVP，這是很多架構師不太去做的，但卻是鋼混架構中的鋼筋水泥，奠定了下限，也註定了上限。
方法論都是特定場景下的沉澱
做架構設計的方法也不少，關鍵是活學活用，比如4+1，比如togaf，還有DDD，ADMEMS這些。但是無論哪個方法論，都是有其特定的上下文場景的，跳出這個場景，也許就不如其他的合適了，比如DDD，非常適合有著複雜的分層架構與職責劃分，對於複用性要求也很高的系統設計，如果只是簡單的CRUD，那DDD反而不合適了。
所以切勿硬搬方法論，就像以前我們會習慣性的硬搬設計模式一樣，多總結，找到適合自己、適合團隊、適合平臺的一套方法來做設計，同時切勿把架構設計純粹做成設計，空談誤國，如何落地才是最重要的，這是架構師在方法論的基礎上最需要注意的。
還有一些講架構的書籍，其實大家也可以多關注，比如《架構之美》，《架構即未來》，《微服務設計》，《領域驅動設計》。
除了方法論，還有一些好方式
讀代碼是個很好的習慣，這10年中，我認為對我架構思路幫助最大的代碼有兩塊，一個是eclipse的源碼，eclipse將extension和extension point用到了極致，有著極強的延伸性考慮。另一個是cloudfoundry的源碼，雖然最終沒有用到產品中，但其在集成維度的抽象考慮，讓我受益很多。現在很多同學還會看openstack、docker的源碼，都是很好的框架，只是受語言能力限制，現在我們團隊還處在怎麼用精的階段。
做驗證也是一個好習慣，互聯網開源技術很多，不可能所有的你都有機會在專案或產品中用到，但很多技術在使用中會給你很多新的思考。記得之前用Hubot和Slack、WeChat做對接玩，我忽然就理解了一些應用生態的建立模式。所以在閒暇之餘，多用一用這些著名的框架，哪怕只是自己玩玩，對自己的認知也是很有幫助的。
勿忘初心，在變與不變中認清自己
還記不記得，10年前你為了什麼奮鬥？
一些新來的團隊成員喜歡問我，在一家公司呆10年是什麼感受，尤其還是從畢業開始。其實這個我也沒有很好的答案，比起很多我的一些朋友和同行，突然就跳到一些大互聯網或創業公司，甚至有做到了CTO，當然也有羡慕，但羡慕之餘，我自認為有兩個點，會使我更沉下心來向前走：
確實我還遠沒到那個水準，現在的崗位已經讓我隱約感受到了彼得定律所到的那層壓力
這一路以來，我是能不斷感受到自己在提升的，而這正是我10年前就在追求的。何況現在的我還處在了一個非常出色的團隊中。
現在的你適合做什麼？
有人說，到了一定階段，你在與不在，對於團隊、公司就顯得沒有那麼重要了。誠然，我也會覺得我現在的角色和能力，早已有團隊成員可替代，所謂的很多公司的高層變動，看似天要塌下來，事實上什麼也沒發生，像阿裡的、丁香園的、中國聯通的、包括像錘子的這些高層變動，大家也都看到了，人家照樣經營的很好。
所以在特定團隊中尋找自己的價值，讓自己過的不“心虛”，是我一直的動力。止於至善，細節決定成敗，永遠把自己看成是最後一班崗，這是我的原則，也是很多公司追求的freedom和responsibility的基礎。至於到底最適合幹什麼，只有努力去做了，才能知道。
直播預告
「 StuQ 公開課 」聯合知乎 Live ，為程式師策劃圍繞熱點技術、實戰案例、職場軟技能培養、職業成長規劃等涵蓋多技術領域技術內容的主題 Live。3月 30 日晚八點半，阿裡巴巴技術專家, 《 React Native 入門與實戰》作者——王利華，將為你帶來「三年從前端小工到架構」。本次分享從一個需求的開始到結束，深挖各個環節，從中發現可以提高效率的方面來解決這些難題，並養成良好的開發習慣。
戳「 閱讀原文 」直通Live。