首頁 > EA > 正文

架構師能力模型

2020-02-28 11:31:40  來源:云原生架構師

摘要:一個合格的架構師到底應該具備哪些能力?
關鍵詞: 架構師 能力模型
架構師在很多人眼中是一個非常高大上的職業, 就像武俠小說中的絕世高手一樣, 關鍵時刻可以起到扭轉乾坤的作用, 是團隊中的靈魂人物. 回想我自己做一線架構師的過程中, 也沒有經歷過比較系統的培訓, 都是摸著石頭過河. 近期在培養架構師的過程中, 促使我一直在思考, 一個合格的架構師到底應該具備哪些能力? 對希望成長為架構師的同學, 或者在承擔架構師職責的同學, 需要提供哪些方面的指導和幫助, 才能讓他逐步成長為合格的架構師呢? 下面我結合自己的經驗, 總結了我認為對架構師來說非常重要的十項能力, 希望給那些努力成長為架構師的同學提供一點點幫助.
 
研發流程的持續改進
 
架構師不是單兵作戰, 憑借個人英雄主義是無法做成大事的. 架構師一定是指揮一個團隊來共同完成既定目標, 或者一個復雜項目. 在軟件研發領域, 決定團隊研發效率的核心在于研發流程的優化. 現階段互聯網公司大多采用敏捷研發流程, 這其中主要包括:
 
需求卡片的狀態流轉. 盡可能依靠工具實現狀態的自動化流轉, 減少人為操作的情況.
開發工具的選擇. 比如web ide, 代碼審查工具, 項目管理工具等.
代碼的開發和審查(包括單測代碼和測試流水線代碼). 開發功能代碼的同時, 必須同時提交單測代碼和測試流水線代碼, 保證新增代碼的基本功能被覆蓋. 盡量不要分開開發, 保證測試代碼的質量.
測試流水線的建設和持續優化. 測試流水線需要在測試覆蓋率和運行時間方面進行平衡, 測試覆蓋率越大勢必會增加測試時間, 如果每次提交pr, 都需要跑很長時間的測試流水線, 那么無疑會降低研發效率. 這時候可以采用測試case分級的方法, 設計ci pileline, daily pipeline, perf pipeline等多條測試流水線, 并且以不同的周期運行.
持續發布和持續部署. 敏捷開發模式核心就是希望通過小步快跑的方式優化傳統瀑布模型的階段性開發模式, 讓每次迭代盡可能快速的得到效果反饋, 從而可以針對反饋更快速的進行軟件迭代. 這就要求我們一定要有持續發布和部署的能力, 可以采用灰度發布, A/B test等模式.
架構師需要對研發流程的每個環節保持著敏銳的嗅覺, 可以及時發現其中的問題, 并提出有效的優化方法. 我們經常討論架構師要不要寫代碼的問題, 在我看來, 不管架構師是否動手寫代碼, 一定要對代碼保持敏感. 保持敏感的方法就是對研發流程保持足夠的把控, 參與代碼審查, 持續的優化研發流程. 做職稱評審的時候, 對于不做code review的架構師我一直是保持懷疑態度的, 我始終認為, 連代碼都不進行review的架構師根本沒辦法真正指導一個項目或者一個技術方向, 至少一線架構師如此.
 
歸納抽象和技術泛化能力
 
架構設計很多情況下我理解就是將共性和差異化的東西分離出來, 共性的部分抽象成獨立的接口, 功能模塊或者組件, 差異化的部分分別形成其他代碼模塊. 那如何識別或者分析出共性的部分, 我認為主要就是依靠架構師的歸納, 抽象和技術泛化能力. 這需要架構師對問題進行反復深入的思考和對比, 透過現象探究事務的本質, 需要架構師擁有舉一反三的能力. 鍛煉這樣的能力, 我覺得可以從日常編寫代碼中體會和訓練. 比如把握好代碼設計的SOLID原則, 在需要的時候對代碼或者架構進行局部重構, 參考寫的更好的代碼或者架構設計等. 另外在日常工作中及時進行總結和復盤也非常有必要, 不要一味地低頭走路, 在每完成一些階段性工作之后, 對自己的工作過程和成果進行總結, 發現其中的優點和缺點, 避免走彎路.
 
業務和需求的分析和理解能力
 
架構的核心是為了業務服務的, 很多架構師覺得自己高高在上, 看不起業務研發同學, 這可不是什么好的想法. 架構就是要讓業務更快速的發展, 所以架構師一定要接地氣. 所謂的接地氣, 我認為就是要加強對業務的深入理解, 能夠預測業務的發展趨勢, 提前在業務需要的技術方向進行適當的布局. 同時對業務提出的需求, 要多問多思考需求背后的本質是什么, 來幫助我們識別并解決業務真正的痛點. 對業務的理解也意味著架構師不會設計出天馬行空不切實際的架構, 可以讓架構師的架構設計更快的落地, 也讓架構師能夠更為順暢的和業務研發同學進行溝通和交流. 所以架構師切忌不可脫離業務, 要時刻保持對業務的一定程度的理解能力.
 
技術折中和持續改進能力
 
很多架構師或者研發工程師都有所謂的代碼或者架構潔癖, 動不動就想重構或者重寫, 并自認為是一種非常好的品質. 這確實在某種程度上體現了工程師的主動性和匠心精神, 但是絕對要把握好時機. 我相信任何一家公司或者任何一個代碼模塊, 都有所謂的技術債務或者實現的不那么好的代碼和架構, 希望短時間內徹底解決是不現實的. 架構師需要能夠識別那些真正的技術債務, 并且要在適當的時機進行適當的重構來解決問題. 技術債務的識別能力是架構師抽象能力和業務理解能力等多方面能力的體現. 適當的時機指的是架構師能夠在一定程度上預測未來的發展趨勢, 同時結合當前的研發任務, 讓架構朝著可以逐步迭代演化的方式來進化到理想目標. 迭代式的發展可以有效降低技術風險, 也可以讓架構師更能充分的把握理想目標. 這個過程要注意避免兩個極端. 一個極端是架構師動輒進行大規模的重構, 一個項目耗時數人年或者更長時間上線. 這種情況不僅項目風險極大, 上線之后非常容易回滾, 而且也大大減少了試錯的機會. 可以說是不成功便成仁. 另一個極端是架構師僅僅就是新功能的建筑師, 不斷的添磚加瓦, 只關注新功能的設計和研發節奏, 而不做任何架構優化工作. 這樣時間久了之后, 項目就會越發難以維護, 周邊類似項目不勝枚舉. 當然上述兩種情形畢竟只是極端情況, 更多的時候還是考察架構師對時機的把握了.
 
技術廣度和深度
 
這一項能力都比較容易理解了. 架構師畢竟仍然是工程師, 而且大都是從一線研發工程師逐步成長和積累起來的, 在某一技術領域或者技術方向通常都有較為深入的理解和積累. 這里我想說的是, 不管是一線研發同學還是架構師, 至少應該在1~2個技術領域有著深入理解的基礎上, 再同時涉獵技術廣度. 如果缺乏對技術基礎知識或者某個技術方向的深入理解, 那想繼續在技術廣度上拓展就非常困難了. 就像那些所謂的武林高手, 通常都有深厚的內功根基, 學習其他武學招數就會特別快一樣. 技術廣度通常也成為技術視野, 計算機技術發展特別迅速, 即使在BAT或者Google/Facebook等世界頂級科技公司, 也切忌固步自封, 要多了解多同類問題的架構設計和解決方案, 取其精華棄其槽粕. 平時多了解多對比相關技術, 在遇到類似問題的時候, 就可以多一些參考信息, 少走一些彎路.
 
持續學習的能力
 
計算機技術發展速度非??? 持續學習能力對于計算機工程師來說都非常重要, 特別是架構師還要求開闊技術視野. 持續學習能力與其說是一種能力, 更多的還是一種習慣的養成. 大家可以自己回想一下, 每天讀多少文章, 每周或者每個月讀幾本書, 平時對于讀到的文章或者書籍有沒有記錄筆記等. 處于信息爆炸的時代, 我們可以接觸到的信息也越來越多, 持續學習能力還要注意信息質量, 注意把握信息的核心內容, 對信息區分精讀和粗讀. 這里我覺得一些付費內容往往質量較高, 正所謂一份價錢一分貨, 為知識付費投資自己還是挺劃算的.
 
技術影響力
 
架構師一定意義上也是某些領域的技術專家, 打造個人技術品牌, 樹立技術影響力對于架構師來說就更為必要了. 現階段技術社區非?;钴S, 架構師可以通過開源項目, 技術論壇, 開設技術課程, 發表學術論文, 在技術類大會上發表演講等多種途徑來提升個人的技術影響力. 可以先從公司內部做起, 平時指導一線工程師的過程中, 注意積累素材, 積累到一定程度之后, 可以開設一些技術類課程, 然后可以到一些技術會議上進行更大范圍的技術演講等. 參與開源社區也是一種比較好的途徑, 同時還可以接觸相關技術圈子, 大家交流技術互通有無, 其樂融融.
 
溝通表達能力
 
作為架構師, 日常工作的溝通或者工作匯報必不可少. 能否將問題和解決方案表達清楚, 對待不同的聽眾, 能否區別的進行溝通都對架構師溝通能力的考察. 我在日常工作中參與過多次的職稱評審, 也參與過無數次的技術評審和工作匯報等會議, 我發現很多架構師的通病就是平時不注意培養溝通表達能力. 有的同學一上來就講解決方案, 很多同學對問題的背景都還不清楚呢, 大家自然對解決方案一頭霧水. 有的同學對解決方案的非關鍵細節花費了大量的時間進行描述, 絲毫沒有全局視角或者整體的介紹, 讓大家聽的是云里霧里. 有的同學在工作匯報時, 對技術方案進行了全方位闡述, 而忽略了對最終結果的介紹, 那大家可以想想老板是什么感受. 有的同學在和其他團隊合作的溝通中, 強勢的要求對方積極配合, 而絲毫沒有替對方考慮的意思, 那這樣的溝通成功率可想而之了.
 
類似的例子不勝枚舉, 那么如何培養溝通能力呢? 我認為首先要能夠站在聽眾的角度思考問題, 明白聽眾真正想要的是什么. 比如做工作匯報的時候, 老板更多的想知道事情的結果, 或者項目的計劃, 對技術細節往往不那么關心. 做技術評審的時候, 評審專家關注整體的架構設計和技術難點的可行性, 對非關鍵細節就不需要過多闡述. 希望和其他團隊合作的話, 盡量從雙贏的角度, 先描述對方的收益, 然后在表達對方需要投入的工作, 這樣往往能夠取得對方的支持.
 
當然溝通表達能力的基礎上是歸納抽象和邏輯思維能力, 如果沒有良好的邏輯, 那么其他一切溝通技巧都是徒勞的. 另外強調一個溝通表達的禮貌問題, 那就是在發表意見之前, 注意傾聽對方的話語, 切忌打斷其他人的講話. 隨意打斷別人的講話, 不僅僅溝通低效, 而且還十分不禮貌, 溝通過程中如果遇到經常打斷別人講話的架構師, 那基本上可以敬而遠之了.
 
技術管理能力
 
架構師不是做完架構設計之后就可以高枕無憂了, 架構師往往要帶領整個研發團隊完成架構的落地. 這就要求架構師即使不是經理角色, 也要具備一定的技術管理能力, 從而帶著整個團隊一起完成工作. 管理工作的核心就是管人, 管事和管錢. 管人就意味著需要和人打交道, 理解團隊成員的特點, 建立良好的信任關系. 管事就意味著管理項目和技術的落地, 包括項目計劃的拆解, 項目執行進度的追蹤, 項目技術難點的攻克等等. 管錢就意味著需要考慮成本的因素, 考慮投入產出比, 考慮激勵因素等. 管理是一門學問, 非常復雜, 我寫在這里是希望架構師不能一味的鉆研業務和技術, 也需要學一些管理方面的知識.
 
堅持正確的價值觀
 
寫在最后我覺得不僅僅是架構師, 一個成功的人, 往往都需要具備正確的價值觀, 這也是我們常說的德才兼備厚德載物吧. 這里不是想讓大家喝雞湯, 而是我覺得任何所謂的能力都可以有意識的構建起來, 但是一個人的價值觀等因素, 卻是很容易被大家忽視. 比如遇到問題, 能不能首先反思自己的問題, 進行自我批評, 而不是僅僅覺得都是外界的問題. 比如遇到困難或者逆境, 能不能有堅定的信念和勇氣. 比如待人接物, 能不能堅持誠信的原則, 能不能信守承諾. 比如面對挑戰和壓力, 能不能有所擔當, 不甩鍋不逃避. 比如面對誤解, 能不能堅持原則, 能不能內心堅強. 諸如此類情況, 還有很多, 我理解這都是構建正確價值觀的一些因素. 這也就是為什么我們常說先學做人, 后學做事的原因吧.
 
架構師是團隊的靈魂人物, 對團隊, 業務和技術的長遠發展起著決定性作用. 所以近期一直思考合格的架構師需要具備哪些能力, 以及如何培養那些高潛的同學成長為架構師. 我相信以上十項能力肯定還不足以覆蓋架構師能力的全部, 特別歡迎同行交流和補充.

本文來源于公眾號:云原生架構師
 

第三十屆CIO班招生
法國布雷斯特商學院碩士班招生
北達軟EXIN網絡空間與IT安全基礎認證培訓
北達軟EXIN DevOps Professional認證培訓
責編:yangjun
有谁不上班靠炒股赚钱 20016期体彩大乐透 彩票网站平台 北京快3推荐号码今天 怎样判断股票涨跌 场外配资合同是什么 青海十一选五走势图今日 快乐北京8根据什么开奖 湖南幸运赛车官网 湖北十一选五爱彩乐app 江苏快3彩票软件下载