架構師不是你想的那樣!
作者|王福強
編輯|小智
戳閱讀原文,獲得簡訊提醒,不錯過下次 InfoQ 大咖說直播!
寫在前面
人人都在說架構師, 但又好像每個人的理解都不一樣,任人難辨。 今天扶牆老師正好借「大咖說」的寶地, 好為人師一把, 笑侃自身的架構師經歷,跟大家分享一下自己對架構師的認知,不管你是在山底,山腰亦或山頂,都希望對志在攀爬「架構師之山」的同學有所幫助。
我的架構師之路
我職業生涯前期最典型的階段是在英極軟體(大連), 這是一家在大連只要有人提起就會「罵娘」的公司, 因為現在互聯網行業很普遍的 996, 其實我在英極的時候就早已習以為常了, 那時候是 2006 年。 很多人都埋怨累, 我聽說有的人入職之後,第二天就離職的。
我當時進英極完全是憑著一股倔強, 因為當時有個很多國人瞧不上的「小日本兒」,o, 不,是「老」日本兒, 一天只睡幾個小時, 但給出的式樣書詳細到偽代碼級別,而且基本沒有錯誤, 當時的 CTO 老王跟著這個日本人對應「廝守」了好幾年了,基本也是這種工作強度,我年紀輕輕的不能輸啊...
在英極的工作中, 處理 Excel 報表是很典型的一個場景,大家都是按照日本人給出的 Excel 報表樣式,用 POI 直接寫代碼畫表格並填充數據,後來,我哪天腦子「抽筋」, 就換了種工作方式, 將日本人給的報表樣式文件拿過來清理後,作為模板讀到程序里,然後直接通過少量代碼設置數值就可以了, 效率大幅提升,後面大家就都依葫蘆畫瓢照著來了, 這算是我做的最小粒度的架構設計了吧。(後面進一步使用 ireport,crystal report 之類的方案,那就更是後話了)
雖然那時候我的 Title 或者 Level 是 Java 程序員,但其實已經在行使架構師的職責了。
2009 年 6 月 23 日入職了阿里巴巴平台技術部, 先後參與並主導了 ROMA Web 框架, EROSA 和 EROMANGA 中間件的設計,開發和推廣工作, 職稱也從高級 Java 工程師,變成了技術專家和高級技術專家,但其實行使的也是架構師的職能:
ROMA 是去架構一個 framework 粒度的程序框架,當然,很多思想是從 SpringMVC 打碎骨架重新拼接出來的;)
Erosa 處理 MySQL 的 binlog 複製, 通過考慮複製鏈路上下游的系統和用戶, 來架構一個通用的數據產品;
Eromanga 是在 Erosa 的場景下結合最早期的 Kafka 思想架構的消息中間件,可以稱為一個獨立運行的完整的軟體系統和產品;
這個階段,我是處理框架和系統粒度的架構師。
如果說作為技術架構師在後面得到大家高度認可的話,那麼, 在阿里巴巴平台技術部的日子不可磨滅, 戲謔點兒說,現在都是在吃那段時間的老本兒 ;) 沒天沒夜的啃英文 papers 和 ebooks, 而這些很多資料都是 2-3 年後才會在國內看到。
2012 年阿里集團內部整合, 我轉崗到了天貓, 負責導購部門的整體架構工作。 從技術層面來說,導購系統大多是圍繞著搜索和推薦系統進行構建; 但從整個導購部門職能來說,需要關注的就不單單是技術就可以的了。
除了連接投放平台, 運營平台等核心導購系統形成導購系統生態鏈,還要去了解流量,用戶,商品,組織結構等不同層面的概念和資源, 雖然其中負責的 SEO 事情沒有做起來(商業上的事兒,自己意會 ^_-),但卻實實在在提升了自己在架構層面的認知, 你不再只單單關注技術, 你還要去關注商業, 組織結構,人等更大範圍的知識域。
架構粒度不再是單一軟體系統,而是多個軟體系統 ; 架構的關注域也不再單單是技術,還有技術之外的事物。
2014 年加入挖財,因為在大連就一直是圍繞著金融做系統,技術上也早有儲備,算是回歸舒適區吧。一進挖財就進了小黑屋, 從最早帶人寫代碼, 跟項目進度,協調人員和資源, 到後期的團隊組織和管理, 算是經歷了從幾十個人到 2016 年離職之前 700+ 人的成長階段。 這個階段的架構粒度有前期的框架, 系統,技術生態,也有後期的組織, 文化和團隊管理。
雖然 2016 年離開挖財有很多原因,但最核心的因素可能是認知和職能的不匹配, 所以, 選擇開啟了新的征程, 選擇了創業。
我個人的整個架構師之路大體上是這個樣子。
前陣子 51 信用卡的孫總希望我作為 CEO 來運營一家子公司,雖然 CEO 確實是我作為架構師的下一個目標, 但股權結構讓我很難心理上「斷奶」,所以,為了繼續對自己狠一點, 我還是回絕了這個 offer, 但還是很感謝孫總的信任。
我眼中的架構師類型
很多同學一定疑惑了, 我們不是在談架構師嗎? 怎麼扯到 CEO 上了那? 其實,架構師只是一種職能,職位或者 title 與職能並不衝突。
架構師其實有很多種類型, 最典型的要數支付寶的魯肅。想當年他的一篇 ppt 將支付寶的整體架構演變闡述地深入淺出, 扶牆老師看了之後,簡直就是膜拜有加。只可惜,當年可以跟隨大咖的機會沒抓住, 悔之晚矣, 而魯肅也從當初的支付寶首席架構師變成了現在螞蟻金付的 CTO, 架構師之路上繼續前行...
為什麼說架構師之路上繼續前行那? 因為 CTO 也是架構師。
作為一位不寫代碼的 CTO, 馮大輝其實是被冤枉的。CTO 負責的是整個技術部的架構, 包括但不限於團隊的組織結構, 團隊文化, 人員的選用育留,薪酬福利等等, 不一而足, 同時還要協調產品, 市場等不同部門的工作,所以, 寫代碼已經不是 CTO 的核心能力和評估標準了, 如何架構好技術部門並協調其它部門,從而很好的支撐公司的業務發展才是 CTO 作為技術部的總架構師的核心職責。 所以, 大輝兄,你受委屈了 ;)
話說回來, 有些 CTO 偶爾寫寫代碼,那也是一種樂趣,比如我們平台技術部的老大 (當年阿里的 P11),偶爾還寫寫 golang 那,但你不能把寫不寫代碼當帽子扣給所有的 CTO 啊,對吧?
馬雲老闆其實也是架構師, 他是阿里這個商業帝國的架構師, 現在估計所有人都不會懷疑他在商業和戰略上的架構能力。
查理芒格是我的第二代偶像(啥? 第一代是誰? 李小龍唄!),也是一名架構師, 他通過駕馭不同領域和學科的知識來幫助巴菲特架構商業投資生態。查理芒格的典型概念主張叫 lollapalooza 效應,是說一旦你可以連接和融會貫通不同領域的知識, 就可以形成一種強大的悟的效應, 而這恰恰是架構師最應該嚮往的境界。
《矽谷》不知道有多少人看過? 裡面的 Peter Gregory 這個人物給我留下了很深的印象。當某公司兩個創始人去找他融資的時候, Gregory 呆木木的坐著喃喃私語遐想了估計 n 個小時,最後直接下了一個交易單, 就為這兩個融資者掙到了需要的融資。 Gregory 屬於典型的深度思考者, 他能夠在深度思考過程中將事件連接,並架構好一個交易鏈條,從而完成最終的商業目的。 跟亮哥運籌帷幄應該有異曲同工之妙吧!
再高一層級的架構師要數我們的鄧小平鄧老了, 國家層面改革開放的總設計師,也是總架構師, 牽動的資源粒度更大,還能在幾十年的時間窗口內推動落地, 這架構師絕對牛!
可以看到, 架構師隨著他能夠處理的架構域不同而不同,架構師也有不同的類型和段位,如果你還在為架構師應不應該寫代碼而鬥嘴,那你應該反思一下自己的架構認知了。
我認為架構師須有的核心能力
Connect Everything
我覺得架構師的核心能力是連接一切的能力,架構師的 Slogan 應該是「連接創造價值」。
現在網上或者書本里,更多是在推崇一萬小時定律之類的理論, 你只要相信一萬小時定律,你就可以成為某個領域的專家,你在職場就可以成為骨幹平步青雲,可是, 為什麼很多 CEO 或者公司老闆既不是專業人士,也沒有勤勤懇懇打磨自己的技能,卻是 CEO 或者公司老闆? 因為沒有人會告訴你, 除了一萬小時定律, 還有「連接創造價值」的架構師之路可以選擇。
圖計算里的圖 Node 固然突出,但離開了 Edge, 還稱得上什麼圖, 產生得了什麼價值?
電話和移動設備固然重要,但離開了電話線和光纖的連接, 也只能當擺設;
人群聚集的社區和城市固然重要, 但離開了路的連接,那也只能雞犬相聞,閉關鎖國了;
專家也好,架構師也罷,都重要,但在大多數人不能確切的理解架構師的情況下,扶牆老師我不得不為架構師代言啦 ;o)
Eager To Learn
一萬小時定律本質上其實是針對同類可重複的事物進行重複性打磨和深入, 但架構師要做的更多是面對未知和新生事物, 所以就需要架構師能夠持續學習,才能勝任這個職能。
做架構師不比做專家輕鬆, 你要持續的學習不同領域的知識, 你要不停的跨界,你要持續的溝通和思考, 只有這樣,你才能「搜集足夠的素材」, 然後再根據當前場景和目標來進行架構和輸出。
Be Open-Minded
我之前很多時候只是在奮聲疾呼大家要 Open-Minded, Open-Minded, 但發現效果不好。後來我明白了, 一個人能不能 Open-Minded, 不在於這個人有沒有這個意識, 而在於這個人有沒有經歷。很多時候, 光有意識是不夠的, 必須自己去經歷過,撞過南牆,然後才能逐步變得開放(Open-Minded)。
記得一次跟杭州氦氪科技的 CEO 聊天, 說道他們的 CTO 自從跟他一起出去跑客戶跑市場之後就變得好溝通多了, 我們倆都不禁會心一笑。確實是這個樣子, 不讓每個人自己去撞撞南牆, 很多時候靠喊是沒有用的。
我很喜歡《瘋狂動物城》里的那首主題歌《Try Everything》, 受其啟發並結合個人經歷,自己總結了一句話,送給大家:
C the world, meet the people and try everything!
Leadership
單單只是勾畫出一幅完美的架構藍圖還遠遠不夠, 一名合格的架構師還要能夠領導或者協調大家一起來將這幅架構藍圖落地, 能否落地,能落地多大的架構藍圖, 往往考驗的就是一名架構師的領導能力。
在不是很複雜的架構域內, 架構師單憑謀事之心一般就可以成事了,但一旦牽扯複雜的架構域, 要謀事且成事,就需要架構師兼有謀人之心, 做到政教合一往往更是可以事半功倍。 不過, 總體上來說, 領導者不是管理者, 謀人謀事,最好是做到「心簡單,腦子複雜」就可以了。如果你願意追求更高段位,那對隨之而來的痛苦和困難要有心理準備 ;)
人人都是架構師
我覺得架構師跟職位和位置等並沒有必然的聯繫, 任何人在任何場景都可以是架構師, 無非架構的粒度和自我的架構認知不同而已。
我一直在強調一名合格的架構師, 但如果非要我劃分更高一檔的架構師的話,還有一檔卓越的架構師, 而責任, 是走向卓越架構師的必經關卡。
今日薦文
TAG:InfoQ |
※走出架構誤區,架構師並不是想像的那麼容易
※究竟是什麼樣的場合,洗手間里遇到的不是架構師就是CTO?
※想要成為一個合格的架構師?看這篇文章就足夠了……
※想要成為架構師拿高薪,不要只是嘴上說說而已
※產品架構師,你的初心是什麼?
※連設計圖都不會畫,你還想做「系統架構師」?
※不懂伺服器的程序猿不是好的架構師
※想成為出色的架構師?這本《聊聊架構》值得你看
※架構師不寫代碼,能行嗎?
※在頂尖架構師眼裡,你遇到的坑都是小問題
※架構師究竟要不要寫代碼?
※代碼只要寫得多,就能成為頂尖的架構師?
※成為架構師的路上,看這一篇文章就足夠了,因為……
※別人的架構都怎麼做的?百餘位架構師的經驗詳解
※成為一名前端架構師需要付出怎樣的努力?
※架構師遇到這些技術瓶頸,應該怎麼辦?
※好的架構師,既要懂微服務也要懂AI?
※成為優秀架構師的第一步是什麼?
※建築師與結構師,你倆到底啥關係?
※極客漫畫:當你僱傭了一個錯誤的架構師