架構師能力模型

https://github.com/elithnever/paperreading/blob/master/%E6%9E%B6%E6%9E%84%E5%B8%88.md#架構師能力模型

架構師能力模型

架構師在不少人眼中是一個很是高大上的職業, 就像武俠小說中的絕世高手同樣, 關鍵時刻能夠起到扭轉乾坤的做用, 是團隊中的靈魂人物. 回想我本身作一線架構師的過程當中, 也沒有經歷過比較系統的培訓, 都是摸着石頭過河. 近期在培養架構師的過程當中, 促使我一直在思考, 一個合格的架構師到底應該具有哪些能力? 對但願成長爲架構師的同窗, 或者在承擔架構師職責的同窗, 須要提供哪些方面的指導和幫助, 才能讓他逐步成長爲合格的架構師呢? 下面我結合本身的經驗, 總結了我認爲對架構師來講很是重要的十項能力, 但願給那些努力成長爲架構師的同窗提供一點點幫助.

研發流程的持續改進

架構師不是單兵做戰, 憑藉我的英雄主義是沒法作成大事的. 架構師必定是指揮一個團隊來共同完成既定目標, 或者一個複雜項目. 在軟件研發領域, 決定團隊研發效率的核心在於研發流程的優化. 現階段互聯網公司大多采用敏捷研發流程, 這其中主要包括:

• 需求卡片的狀態流轉. 儘量依靠工具實現狀態的自動化流轉, 減小人爲操做的狀況.
• 開發工具的選擇. 好比web ide, 代碼審查工具, 項目管理工具等.
• 代碼的開發和審查(包括單測代碼和測試流水線代碼). 開發功能代碼的同時, 必須同時提交單測代碼和測試流水線代碼, 保證新增代碼的基本功能被覆蓋. 儘可能不要分開開發, 保證測試代碼的質量.
• 測試流水線的建設和持續優化. 測試流水線須要在測試覆蓋率和運行時間方面進行平衡, 測試覆蓋率越大勢必會增長測試時間, 若是每次提交pr, 都須要跑很長時間的測試流水線, 那麼無疑會下降研發效率. 這時候能夠採用測試case分級的方法, 設計ci pileline, daily pipeline, perf pipeline等多條測試流水線, 而且以不一樣的週期運行.
• 持續發佈和持續部署. 敏捷開發模式核心就是但願經過小步快跑的方式優化傳統瀑布模型的階段性開發模式, 讓每次迭代儘量快速的獲得效果反饋, 從而能夠針對反饋更快速的進行軟件迭代. 這就要求咱們必定要有持續發佈和部署的能力, 能夠採用灰度發佈, A/B test等模式.

架構師須要對研發流程的每一個環節保持着敏銳的嗅覺, 能夠及時發現其中的問題, 並提出有效的優化方法. 咱們常常討論架構師要不要寫代碼的問題, 在我看來, 無論架構師是否動手寫代碼, 必定要對代碼保持敏感. 保持敏感的方法就是對研發流程保持足夠的把控, 參與代碼審查, 持續的優化研發流程. 作職稱評審的時候, 對於不作code review的架構師我一直是保持懷疑態度的, 我始終認爲, 連代碼都不進行review的架構師根本沒辦法真正指導一個項目或者一個技術方向, 至少一線架構師如此.

概括抽象和技術泛化能力

架構設計不少狀況下我理解就是將共性和差別化的東西分離出來, 共性的部分抽象成獨立的接口, 功能模塊或者組件, 差別化的部分分別造成其餘代碼模塊. 那如何識別或者分析出共性的部分, 我認爲主要就是依靠架構師的概括, 抽象和技術泛化能力. 這須要架構師對問題進行反覆深刻的思考和對比, 透過現象探究事務的本質, 須要架構師擁有觸類旁通的能力. 鍛鍊這樣的能力, 我以爲能夠從平常編寫代碼中體會和訓練. 好比把握好代碼設計的SOLID原則, 在須要的時候對代碼或者架構進行局部重構, 參考寫的更好的代碼或者架構設計等. 另外在平常工做中及時進行總結和覆盤也很是有必要, 不要一味地低頭走路, 在每完成一些階段性工做以後, 對本身的工做過程和成果進行總結, 發現其中的優勢和缺點, 避免走彎路.

業務和需求的分析和理解能力

架構的核心是爲了業務服務的, 不少架構師以爲本身高高在上, 看不起業務研發同窗, 這可不是什麼好的想法. 架構就是要讓業務更快速的發展, 因此架構師必定要接地氣. 所謂的接地氣, 我認爲就是要增強對業務的深刻理解, 可以預測業務的發展趨勢, 提早在業務須要的技術方向進行適當的佈局. 同時對業務提出的需求, 要多問多思考需求背後的本質是什麼, 來幫助咱們識別並解決業務真正的痛點. 對業務的理解也意味着架構師不會設計出天馬行空不切實際的架構, 可讓架構師的架構設計更快的落地, 也讓架構師可以更爲順暢的和業務研發同窗進行溝通和交流. 因此架構師切忌不可脫離業務, 要時刻保持對業務的必定程度的理解能力.

技術折中和持續改進能力

不少架構師或者研發工程師都有所謂的代碼或者架構潔癖, 動不動就想重構或者重寫, 並自認爲是一種很是好的品質. 這確實在某種程度上體現了工程師的主動性和匠心精神, 可是絕對要把握好時機. 我相信任何一家公司或者任何一個代碼模塊, 都有所謂的技術債務或者實現的不那麼好的代碼和架構, 但願短期內完全解決是不現實的. 架構師須要可以識別那些真正的技術債務, 而且要在適當的時機進行適當的重構來解決問題. 技術債務的識別能力是架構師抽象能力和業務理解能力等多方面能力的體現. 適當的時機指的是架構師可以在必定程度上預測將來的發展趨勢, 同時結合當前的研發任務, 讓架構朝着能夠逐步迭代演化的方式來進化到理想目標. 迭代式的發展能夠有效下降技術風險, 也可讓架構師更能充分的把握理想目標. 這個過程要注意避免兩個極端. 一個極端是架構師動輒進行大規模的重構, 一個項目耗時數人年或者更長時間上線. 這種狀況不只項目風險極大, 上線以後很是容易回滾, 並且也大大減小了試錯的機會. 能夠說是不成功便成仁. 另外一個極端是架構師僅僅就是新功能的建築師, 不斷的添磚加瓦, 只關注新功能的設計和研發節奏, 而不作任何架構優化工做. 這樣時間久了以後, 項目就會愈加難以維護, 周邊相似項目不勝枚舉. 固然上述兩種情形畢竟只是極端狀況, 更多的時候仍是考察架構師對時機的把握了.

技術廣度和深度

這一項能力都比較容易理解了. 架構師畢竟仍然是工程師, 並且大都是從一線研發工程師逐步成長和積累起來的, 在某一技術領域或者技術方向一般都有較爲深刻的理解和積累. 這裏我想說的是, 無論是一線研發同窗仍是架構師, 至少應該在1~2個技術領域有着深刻理解的基礎上, 再同時涉獵技術廣度. 若是缺少對技術基礎知識或者某個技術方向的深刻理解, 那想繼續在技術廣度上拓展就很是困難了. 就像那些所謂的武林高手, 一般都有深厚的內功根基, 學習其餘武學招數就會特別快同樣. 技術廣度一般也成爲技術視野, 計算機技術發展特別迅速, 即便在BAT或者Google/Facebook等世界頂級科技公司, 也切忌固步自封, 要多瞭解多同類問題的架構設計和解決方案, 取其精華棄其槽粕. 平時多瞭解多對比相關技術, 在遇到相似問題的時候, 就能夠多一些參考信息, 少走一些彎路.

持續學習的能力

計算機技術發展速度很是快, 持續學習能力對於計算機工程師來講都很是重要, 特別是架構師還要求開闊技術視野. 持續學習能力與其說是一種能力, 更多的仍是一種習慣的養成. 你們能夠本身回想一下, 天天讀多少文章, 每週或者每月讀幾本書, 平時對於讀到的文章或者書籍有沒有記錄筆記等. 處於信息爆炸的時代, 咱們能夠接觸到的信息也愈來愈多, 持續學習能力還要注意信息質量, 注意把握信息的核心內容, 對信息區分精讀和粗讀. 這裏我以爲一些付費內容每每質量較高, 正所謂一份價錢一分貨, 爲知識付費投資本身仍是挺划算的.

技術影響力

架構師必定意義上也是某些領域的技術專家, 打造我的技術品牌, 樹立技術影響力對於架構師來講就更爲必要了. 現階段技術社區很是活躍, 架構師能夠經過開源項目, 技術論壇, 開設技術課程, 發表學術論文, 在技術類大會上發表演講等多種途徑來提高我的的技術影響力. 能夠先從公司內部作起, 平時指導一線工程師的過程當中, 注意積累素材, 積累到必定程度以後, 能夠開設一些技術類課程, 而後能夠到一些技術會議上進行更大範圍的技術演講等. 參與開源社區也是一種比較好的途徑, 同時還能夠接觸相關技術圈子, 你們交流技術互通有無, 其樂融融.

溝通表達能力

做爲架構師, 平常工做的溝通或者工做彙報必不可少. 可否將問題和解決方案表達清楚, 對待不一樣的聽衆, 可否區別的進行溝通都對架構師溝通能力的考察. 我在平常工做中參與過屢次的職稱評審, 也參與過無數次的技術評審和工做彙報等會議, 我發現不少架構師的通病就是平時不注意培養溝通表達能力. 有的同窗一上來就講解決方案, 不少同窗對問題的背景都還不清楚呢, 你們天然對解決方案一頭霧水. 有的同窗對解決方案的非關鍵細節花費了大量的時間進行描述, 絲毫沒有全局視角或者總體的介紹, 讓你們聽的是雲裏霧裏. 有的同窗在工做彙報時, 對技術方案進行了全方位闡述, 而忽略了對最終結果的介紹, 那你們能夠想一想老闆是什麼感覺. 有的同窗在和其餘團隊合做的溝通中, 強勢的要求對方積極配合, 而絲毫沒有替對方考慮的意思, 那這樣的溝通成功率可想而之了.

相似的例子不勝枚舉, 那麼如何培養溝通能力呢? 我認爲首先要可以站在聽衆的角度思考問題, 明白聽衆真正想要的是什麼. 好比作工做彙報的時候, 老闆更多的想知道事情的結果, 或者項目的計劃, 對技術細節每每不那麼關心. 作技術評審的時候, 評審專家關注總體的架構設計和技術難點的可行性, 對非關鍵細節就不須要過多闡述. 但願和其餘團隊合做的話, 儘可能從共贏的角度, 先描述對方的收益, 而後在表達對方須要投入的工做, 這樣每每可以取得對方的支持.

固然溝通表達能力的基礎上是概括抽象和邏輯思惟能力, 若是沒有良好的邏輯, 那麼其餘一切溝通技巧都是徒勞的. 另外強調一個溝通表達的禮貌問題, 那就是在發表意見以前, 注意傾聽對方的話語, 切忌打斷其餘人的講話. 隨意打斷別人的講話, 不只僅溝通低效, 並且還十分不禮貌, 溝經過程中若是遇到常常打斷別人講話的架構師, 那基本上能夠敬而遠之了.

技術管理能力

架構師不是作完架構設計以後就能夠高枕無憂了, 架構師每每要帶領整個研發團隊完成架構的落地. 這就要求架構師即便不是經理角色, 也要具有必定的技術管理能力, 從而帶着整個團隊一塊兒完成工做. 管理工做的核心就是管人, 管事和管錢. 管人就意味着須要和人打交道, 理解團隊成員的特色, 創建良好的信任關係. 管事就意味着管理項目和技術的落地, 包括項目計劃的拆解, 項目執行進度的追蹤, 項目技術難點的攻克等等. 管錢就意味着須要考慮成本的因素, 考慮投入產出比, 考慮激勵因素等. 管理是一門學問, 很是複雜, 我寫在這裏是但願架構師不能一味的鑽研業務和技術, 也須要學一些管理方面的知識.

堅持正確的價值觀

寫在最後我以爲不只僅是架構師, 一個成功的人, 每每都須要具有正確的價值觀, 這也是咱們常說的德才兼備. 我這裏不是想讓你們喝雞湯, 而是我以爲任何所謂的能力均可以有意識的構建起來, 可是一我的的價值觀等因素, 倒是很容易被你們忽視. 好比遇到問題, 能不能首先反思本身的問題, 進行自我批評, 而不是僅僅以爲都是外界的問題. 好比遇到困難或者逆境, 能不能有堅決的信念和勇氣. 好比待人接物, 能不能堅持誠信的原則, 能不能信守承諾. 好比面對挑戰和壓力, 能不能有所擔當, 不甩鍋不逃避. 好比面對誤解, 能不能堅持原則, 能不能心裏堅強. 諸如此類狀況, 還有不少, 我理解這都是構建正確價值觀的一些因素. 這也就是爲何咱們常說先學作人, 在學作事的緣由吧.