轉自雲狄 阿里高級技術專家的一篇文章
阿里妹導讀：技術主管，又叫「技術經理」，英文一般是 Tech Leader ，簡
稱 TL。隨着工作經驗的不斷積累，能力的不斷提升，每個人都有機會成爲 Team
Leader。然而在機會到來前，我們必須提前做好準備，對 TL 的工作職責有一定了
解。當然，這也會爲當下更好地配合 TL 工作打下基礎。
阿里巴巴高級技術專家雲狄將結合自己多年的經驗，從開發規範、開發流程、技
術規劃與管理三個角度出發，分享對技術 TL 這一角色的理解與思考。
-
「技術主管」是開發團隊中的某位程序員需要對一起創建系統的整個開發團隊負
責時所承擔的角色。通常他既要對最終交付的軟件系統負責，另外也會像一個程序員
一樣去開發實現系統。 -
一個技術主管的 60% ～ 70% 的時間可能花在了開發任務分解分配、開發實踐、
技術架構評審、代碼審覈和風險識別上，而餘下的 30% ～ 40% 的時間則花在爲了 -
保障系統按時交付所需的各種計劃、協作、溝通、管理上。和團隊管理者不同的是，
技術主管的大部分管理工作都是針對具體研發任務和技術事務的。
接下來基於我在技術 TL 這個角色上，在開發規範、開發流程、技術管理與規劃
等方面我的一些心路歷程，和大家共勉。
開發規範
我當時負責的業務是集團收購一家子公司的業務，在整體技術標規範上與集團的
技術標準存在很大的差異。開發規範可以說是我來到這個團隊乾的第一件事，我當時
面對的問題是 API 接口格式混亂，沒有標準的 RPC 服務化，代碼沒有統一標準的開
發規範，技術框架組件非標準化等一系列問題，作爲一名業務上的新人，我第一時間
制定了一套相對標準、全面的技術開發規範，邊寫代碼邊梳理開發規範，引領團隊走
向統一標準化開發道路。
針對團隊研發規範暴露的上述問題，主要制定瞭如下規範：
命名規範
我自己非常注重搭建項目結構的起步過程，應用命名規範、模塊的劃分、目錄
（包）的命名，我覺得非常重要，如果做的足夠好，別人導入項目後可能只需要 10 分
鍾就可以大概瞭解系統結構。
具體規範包括包命名、類的命名、接口命名、方法命名、變量命名、常量命名。
統一 IDE 代碼模板
約定了 IDEA/Eclipse IDE 代碼的統一模板，代碼風格一定要統一，避免不同開
發人員使用不同模板帶來的差異化以及代碼 merge 成本。使用 IDEA 的同學可以安
裝 Eclipse Code Formatter 插件，和 Eclipse 統一代碼模板。
Maven 使用規範
所有二方庫、三方庫的版本統一定義到 parent pom 裏，這樣來所有業務應用工
程統一繼承 parent pom 裏所指定的二方庫、三方庫的版本，統一框架與工具的版本
(Spring、Apache commons 工具類、日誌組件、JSON 處理、數據庫連接池等 )，
同時要求生產環境禁用 SNAPSHOT 版本。這樣以來升級通用框架與工具的版本，
只需要應用工程升級 parent pom 即可。
代碼 Commit 規範
基於 Angular Commit Message 規範生成統一的 ChangeLog，這樣一來對於
每次發佈 release tag 非常清晰，Mac 下都需要安裝對應的插件，IDEA 也有對應的
插件，具體可以參考阮一峯老師的《Commit message 和 Change log 編寫指南》。
此刻忽然想起 Linus 面對 pull request 裏的騷操作所發的飈：
Get rid of it. And I don’t ever want to see that shit again. ——Linus
代碼的 commit 的規範對團隊非常重要，清晰的 commit 信息生成的 release
tag，對於生產環境的故障回滾業非常關鍵，能夠提供一些有價值的信息。
統一 API 規範
統一 Rpc 服務接口的返回值 ResultDTO, 具體代碼如下：
/**
* Created by honins on 2019/9/26 14:50
* @author honins
*/
public class ResultDTO<T extends Serializable> implements Serializable {
private String errorCode;
private String errorMsg;
private Boolean success;
private T module;
@Override
public String toString() {
return "ResultDTO{" +
"errorCode='" + errorCode + '\'' +
", errorMsg='" + errorMsg + '\'' +
", success=" + success +
", module=" + module +
'}';
}
}
success 代 表 接 口 處 理 響 應 結 果 成 功 還 是 失 敗，errorCode、errorMsg 表
示 返 回 錯 誤 碼 和 錯 誤 消 息，module 表 示 返 回 結 果 集， 把 ResultDTO 定 義 到
common-api 頂層二方庫，這樣以來各個應用不需要來回轉換返回結果。
Http Rest 接口規範約定同 ResultDTO 相差無幾，需要額外關注一下加解密規
範和簽名規範、版本管理規範。
異常處理規範
異常處理不僅僅是狹義上遇到了 Exception 怎麼去處理，還有各種業務邏輯遇
到錯誤的時候我們怎麼去處理。service 服務層捕獲的異常主要包括 BusinessException( 業務異常 )、RetriableException ( 可重試異常 ) 到 common-api，定義一個公共異常攔截器，對業務異常、重試異常進行統一處理，對於可重試的異常調用的服務接口需要保證其冪等性。
另外其他業務層有些特殊異常不需要攔截器統一處理，內部可以進行自我消化處
理掉，根據場景對應的處理原則主要包括：
- 直接返回
- 拋出異常
- 重試處理
- 熔斷處理
- 降級處理
這又涉及到了彈力設計的話題，我們的系統往往會對接各種依賴外部服務、Api，
大部分服務都不會有 SLA，即使有在大併發下我們也需要考慮外部服務不可用對自
己的影響，會不會把自己拖死。
我們總是希望： - 儘可能以小的代價通過嘗試讓業務可以完成；
- 如果外部服務基本不可用，而我們又同步調用外部服務的話，我們需要進行自
我保護直接熔斷，否則在持續的併發的情況下自己就會垮了； - 如果外部服務特別重要，我們往往會考慮引入多個同類型的服務，根據價格、
服務標準做路由，在出現問題的時候自動降級。
推薦使用 Netflix 開源的 hystrix 容災框架，主要解決當外部依賴出現故障時拖垮
業務系統、甚至引起雪崩的問題。目前我團隊也在使用，能夠很好的解決異常熔斷、
超時熔斷、基於併發數限流熔斷的降級處理。
分支開發規範
早期的時候源碼的版本管理基於 svn，後來逐步切換到 git，分支如何管理每一
個公司（在 Gitflow 的基礎上）都會略有不同。
針對分支開發規範，指定如下標準：
- 分支的定義（master、develop、release、hotfix、feature）
- 分支命名規範
- checkout、merge request 流程
- 提測流程
- 上線流程
- Hotfix 流程，雖然這個和代碼質量和架構無關，按照這一套標準執行下來，能夠給整個研發團
隊帶領很大的便利： - 減少甚至杜絕代碼管理導致的線上事故；
- 提高開發和測試的工作效率，人多也亂；
- 減少甚至杜絕代碼管理導致的線上事故；
- 方便運維處理髮布和回滾；
- 讓項目的開發可以靈活適應多變的需求，多人協同開發。
統一日誌規範
日誌是產品必不可少的一個功能，具備可回溯性、能夠抓取問題現場信息是其獨
一無二的優點，尤其在生產系統上問題定位等方面具有不可替代的作用。
這裏着重強調一下針對異常的日誌規範：
- WARN 和 ERROR 的選擇需要好好考慮，WARN 一般我傾向於記錄可自恢
復但值得關注的錯誤，ERROR 代表了不能自己恢復的錯誤。對於業務處理遇
到問題用 ERROR 不合理，對於 catch 到了異常也不是全用 ERROR。 - 記錄哪些信息，最好打印一定的上下文（鏈路 TraceId、用戶 Id、訂單 Id、外
部傳來的關鍵數據）而不僅僅是打印線程棧。 - 記錄了上下問信息，是否要考慮日誌脫敏問題？可以在框架層面實現，比如自
定義實現 logback 的 ClassicConverter。
正確合理的使用日誌，能夠指引開發人員快速查找錯誤、定位問題，因此約定了
一套日誌使用標準規範，現在可以更多的參考《阿里經濟體開發規約——日誌規約》。
統一 MYSQL 開發規範
表的設計和 Api 的定義類似，屬於那種開頭沒有開好，以後改變需要花 10x 代
價的，我知道，一開始在業務不明確的情況下，設計出良好的一步到位的表結構很困
難，但是至少我們可以做的是有一個好的標準。
統一工具與框架
對開發過程中所用到的公共組件進行了統一抽象與封裝，包括 dao 層框架
mybatis、cache 組件 jetcache、httpclien t 組件、common-tools ( 公共工具 )，
同時抽取出全局唯一 ID、分佈式鎖、冪等等公共組件，把以上公共組件進行集成到各
個應用，進行統一升級、維護，這樣以來方便大家將更多的精力集中到業務開發上。
開發流程
目前團隊的開發模式還是基於傳統的瀑布開發模式，整體開發流程涉及需求評
審、測試用例評審、技術架構評審、開發與測試、驗收與上線，這裏主要基於 TL 的
角度從需求管理、技術架構評審、代碼評審、發佈計劃評審幾個關鍵重點環節進行探
討，歡迎拍磚。
需求管理
美國專門從事跟蹤 IT 項目成功或失敗的權威機構 Standish Group 的 CHAOS
Reports 報導了該公司的一項研究，該公司對多個項目作調查後發現，百分之七十四
的項目是失敗的，既這些項目不能按時按預算完成。其中提到最多的導致項目失敗的
原因就是變更用戶需求。另外從歷年的 Standish Group 報告分析看，導致項目
失敗的最重要原因與需求有關。Standish Group 的 CHAOS 報告進一步證實了與成
功項目最密切的因素是良好的需求管理，也就是項目的範圍管理，特別是管理好項目
的變更。
產品因需求而生，在產品的整個生命週期中，產品經理會收到來自各個方面的需求，但是每一個需求的必要性、重要性和實現成本都需要經過深思熟慮的分析和計劃，避免盲目的決定需求或者變更需求，這樣很容易導致工作混亂，技術 TL 如果不能正確的對需求進行把控，會導致整個項目偏離正確的軌道。
- 需求管理的第一步就是要梳理不同來源的需求，主要包括從產品定位出發、外
部用戶反饋、競爭對手情況、市場變化以及內部運營人員、客服人員、開發人員的反
饋。首先技術 TL 對產品有足夠認知和把控，簡單來說就是我的產品是爲了滿足哪些
人的哪些需求而做，產品需求一定要根植於客戶的需求、根植於客戶的環境。每款產
品必定有其核心價值，能夠爲客戶創造更多的價值，基於此考慮往往能得到一些核心
需求，摒除價值不大的需求。 - 需求管理中最重要的就是對發散性需求的管理，往往因此也會導致產品在執行過
程中不斷的變更或增加需求。由於人的思維是發散性的，所以往往在產品構思的過程
中會出現各種新鮮好玩的想法，這些想法可能來自領導或者產品經理自己，但是這些
想法往往都是和產品核心方向不相關的，但是由於這些想法能夠在當時帶來誘惑，因
此這些不相關的需求會嚴重干擾了技術團隊的精力，打亂或者延誤產品原本的計劃。
同樣技術研發同學也需要建立對產品的深度思考，不要把自己定位成產品需求的實現
者，同樣需要對需求負責。
很多時候需求的變更或增加是因爲我們面臨太多選擇和想要的太多，沒有適當的
控制自己的慾望，並以自己的喜好來決定需求，這些因素很容易導致產品沒有明確的
方向、團隊成員疲於奔命，但是卻沒有實際的成果。所以技術 TL 一定要能夠評估出
重新審視產品和篩選需求的優先級，識別每一個需求的必要性、重要性和實現成本。
通過深思熟慮給團隊明確方向並專注，聚焦資源的支配，確保團隊的精力都聚焦在產
品的核心需求上。
技術架構評審
互聯網時代，大家提倡敏捷迭代，總嫌傳統方式太重，流程複雜，影響效率，什
麼都希望短平快，在扁平化的組織中，經常是需求火速分發到一線研發，然後就靠個
人折騰去了，其實技術架構評審這同樣是一個非常重要的環節。架構評審或技術方案
評審的價值在於集衆人的力量大家一起來分析看看方案裏是否有坑，方案上線後是否
會遇到不可逾越的重大技術問題，提前儘可能把一些事情先考慮到提出質疑其實對項
目的健康發展有很大的好處。
基於架構評審，我們的目標核心是要滿足以下幾點：
- 設計把關，確保方案合格，各方面都考慮到了，避免缺陷和遺漏，不求方案
多牛，至少不犯錯。 - 保證架構設計合理和基本一致，符合整體原則。
- 維持對系統架構的全局認知，避免黑盒效應。
- 通過評審發掘創新亮點，推廣最佳實踐。
架構設計既要保證架構設計的合理性和可擴展性，又要避免過度設計。架構設計
不僅僅是考慮功能實現，還有很多非功能需求，以及持續運維所需要的工作，需要工
程實踐經驗，進行平衡和取捨。
架構評審需要以下幾點：
- 技術選型：爲什麼選用 A 組件不選用 B、C 組件，A 是開源的，開源協議是
啥？基於什麼語言開發的，出了問題我們自身是否能夠維護？性能方面有沒
有壓測過？這些所有問題作爲技術選型我們都需要考慮清楚，才能做最終決定。
阿里工程師的自我修養 < 113 - 高性能：產品對應的 TPS、QPS 和 RT 是多少？設計上會做到的 TPS、
QPS 和 RT 是多少？而實際上我們整體隨着數據量的增大系統性能會不會出
現明顯問題？隨着業務量、數據量的上升，我們的系統的性能如何去進一步
提高？系統哪個環節會是最大的瓶頸？是否有抗突發性能壓力的能力，大概
可以滿足多少的 TPS 和 QPS，怎麼去做來實現高性能，這些問題都需要我
們去思考。 - 高可用：是否有單點的組件，非單點的組件如何做故障轉移？是否考慮過多活
的方案？是否有數據丟失的可能性？數據丟失如何恢復？出現系統宕機情況，
對業務會造成哪些影響？有無其他補救方案？這些問題需要想清楚，有相應
的解決方案。 - 可擴展性：A 和 B 的業務策略相差無幾，後面會不會繼續衍生出 C 的業務策
略，隨着業務的發展哪些環節可以做擴展，如何做擴展？架構設計上需要考
慮到業務的可擴展性。 - 可伸縮性：每個環節的服務是不是無狀態的？是否都是可以快速橫向擴展的？
擴容需要怎麼做手動還是自動？擴展後是否可以提高響應速度？這所有的問
題都需要我們去思考清楚，並有對應的解決方案。 - 彈性處理：消息重複消費、接口重複調用對應的服務是否保證冪等？是否考慮
了服務降級？哪些業務支持降級？支持自動降級還是手工降級？是否考慮了
服務的超時熔斷、異常熔斷、限流熔斷？觸發熔斷後對客戶的影響？服務是
否做了隔離，單一服務故障是否影響全局？這些問題統統需要我們想清楚對
應的解決方案，纔會進一步保證架構設計的合理性。 - 兼容性：上下游依賴是否梳理過，影響範圍多大？怎麼進行新老系統替換？新
老系統能否來回切換？數據存儲是否兼容老的數據處理？如果對你的上下游
系統有影響，是否通知到上下游業務方？上下游依賴方進行升級的方案成本
如何最小化？這些問題需要有完美的解決方案，稍有不慎會導致故障。 - 安全性：是否徹底避免 SQL 注入和 XSS ？是否有數據泄露的可能性？是否
做了風控策略？接口服務是否有防刷保護機制？數據、功能權限是否做了控
制？小二後臺系統是否做了日誌審計？數據傳輸是否加密驗籤？應用代碼中
是否有明文的 AK/SK、密碼？這些安全細節問題需要我們統統考慮清楚，安
全問題任何時候都不能輕視。 - 可測性：測試環境和線上的差異多大？是否可以在線上做壓測？線上壓測怎
麼隔離測試數據？是否有測試白名單功能？是否支持部署多套隔離的測試環
境？測試黑盒白盒工作量的比例是怎麼樣的？新的方案是否非常方便測試，
在一定程度也需要考量。 - 可運維性：系統是否有初始化或預熱的環節？數據是否指數級別遞增？業務
數據是否需要定期歸檔處理？隨着時間的推移如果壓力保持不變的話系統需
要怎麼來巡檢和維護？業務運維方面的設計也需要充分考慮到。 - 監控與報警：對外部依賴的接口是否添加了監控與報警？應用層面系統內部
是否有暴露了一些指標作監控和報警？系統層面使用的中間件和存儲是否有
監控報警？只有充分考慮到各個環節的監控、報警，任何問題會第一時間通
知到研發，阻止故障進一步擴散。
其實不同階段的項目有不同的目標，我們不會在項目起步的時候做 99.99% 的
可用性支持百萬 QPS 的架構，高效完成項目的業務目標也是架構考慮的因素之一。
而且隨着項目的發展，隨着公司中間件和容器的標準化，很多架構的工作被標準化替
代，業務代碼需要考慮架構方面伸縮性運維性等等的需求越來越少，慢慢的這些工作
都能由架構和運維團隊來接。一開始的時候我們可以花一點時間來考慮這些問題，但
是不是所有的問題都需要有最終的方案。
代碼評審
代碼質量包括功能性代碼質量和非功能性代碼質量，功能質量大多通過測試能
夠去發現問題，非功能性代碼質量用戶不能直接體驗到這種質量的好壞，代碼質量不
好，最直接的“受害者”是開發者或組織自身，因爲代碼質量好壞直接決定了軟件的
可維護性成本的高低。代碼質量應該更多的應該從可測性，可讀性，可理解性，容變
性等代碼可維護性維度去衡量，其中 CodeReview 是保證代碼質量非常重要的一個
環節，建立良好的 CodeReview 規範與習慣，對於一個技術團隊是一件非常重要核
心的事情，沒有 CodeReview 的團隊沒有未來。
每次項目開發自測完成後，通常會組織該小組開發人員集體進行代碼 review，
代碼 review 一般 review 代碼質量以及規範方面的問題，另外需要關注的是每一行
代碼變更是否與本次需求相關，如果存在搭車發佈或者代碼重構優化，需要自行保證
測試通過，否則不予發佈。
CodeReview 我會重點關注如下事情：
- 確認代碼功能：代碼實現的功能滿足產品需求，邏輯的嚴謹和合理性是最基本
的要求。同時需要考慮適當的擴展性，在代碼的可擴展性和過度設計做出權
衡，不編寫無用邏輯和一些與代碼功能無關的附加代碼。
在真正需要某些功能的時候纔去實現它，而不是你預見到它將會有用。
—— RonJeffries - 編碼規範：以集團開發規約、靜態代碼規約爲前提，是否遵守了編碼規範，遵
循了最佳實踐。除了形式上的要求外，更重要的是命名規範。目標是提高代
碼的可讀性，降低代碼可維護性成本。 - 潛在的 BUG：可能在最壞情況下出現問題的代碼，包括常見的線程安全、業
務邏輯準確性、系統邊界範圍、參數校驗，以及存在安全漏洞 ( 業務鑑權、灰
產可利用漏洞 ) 的代碼。 - 文檔和註釋：過少（缺少必要信息）、過多（沒有信息量）、過時的文檔或註釋，
總之文檔和註釋要與時俱進，與最新代碼保持同步。其實很多時候個人覺得
良好的變量、函數命名是最好的註釋，好的代碼勝過註釋。 - 重複代碼：當一個項目在不斷開發迭代、功能累加的過程中，重複代碼的出現
幾乎是不可避免的，通常可以通過 PMD 工具進行檢測。類型體系之外的重複
代碼處理通常可以封裝到對應的 Util 類或者 Helper 類中，類體系之內的重複
代碼通常可以通過繼承、模板模式等方法來解決。 - 複雜度：代碼結構太複雜（如圈複雜度高），難以理解、測試和維護。
- 監控與報警：基於產品的需求邏輯，需要有些指標來證明業務是正常 work
的，如果發生異常需要有監控、報警指標通知研發人員處理，review 業務需
求對應的監控與報警指標也是 Code Review 的重點事項。 - 測試覆蓋率：編寫單元測試，特別是針對複雜代碼的測試覆蓋是否足夠。
實際上維護單元測試的成本不比開發成本低，這點團隊目前做的的不到位。
針對以上每次代碼 review 所涉及到的經典案例會統一輸出到文檔裏，大家可以
共同學習避免編寫出同樣的 Ugly Code。
發佈計劃評審
涉及到 10 人日以上的項目，必須有明確的發佈計劃，並組織項目成員統一參加
項目發佈計劃 review，發佈計劃主要包含如下幾點：
- 明確是否有外部依賴接口，如有請同步協調好業務方；
- 發佈前配置確認包括配置文件、數據庫配置、中間件配置等各種配置，尤其
各種環境下的差異化配置項； - 二方庫發佈順序，是否有依賴；
- 應用發佈順序；
- 數據庫是否有數據變更和訂正，以及表結構調整；
- 回滾計劃，必須要有回滾計劃，發佈出現問題要有緊急回滾策略；
- 生產環境迴歸測試重點 Case。
技術規劃與管理
我在帶技術團隊的這些年，對團隊一直有一個要求，每週都要做系統健康度巡
檢，未雨綢繆、晴天修屋頂，避免在極端場景下某些隱藏的 bug 轉變成了故障。
系統健康度巡檢
爲什麼要把系統健康度巡檢放到技術管理裏，我覺得這是一個非常重要的環節。
像傳統的航空、電力、汽車行業都要有一定的巡檢機制，保障設備系統正常運轉，同
樣軟件系統也同樣需要巡檢機制保障業務健康發展。
隨着業務的不斷髮展，業務量和數據量不斷的上漲，系統架構的腐蝕是避免不了
的，爲了保障系統的健康度，需要不斷的考慮對系統架構、性能進行優化。
系統的監控與報警能夠一定程度發現系統存在的問題，系統存在的一些隱患需要
通過對系統的巡檢去發現，如果優化不及時在極端情況會導致故障，巡檢粒度建議每
周巡檢一次自己所負責的業務系統。
系統巡檢重點要關注如下幾點：
- 系統指標：系統 CPU、負載、內存、網絡、磁盤有無異常情況波動，確認是
否由發佈導致，還是系統調用異常。 - 慢接口：通常 rt 大於 3s 的接口需要重點關注，極端併發場景下容易導致整個
系統雪崩。 - 慢查詢：MYSQL 慢查詢需要重點關注，隨着數據量上漲，需要對慢查詢進行
優化。 - 錯誤日誌：通過錯誤日誌去發現系統隱藏的一些 bug，避免這些 bug 被放大，
甚至極端情況下會導致故障。
技術規劃
技術規劃通常由團隊的 TL 負責，每個財年 TL 需要從大局的角度去思考每個季
度的技術優化規劃，去償還技術債，技術債也是有利息的，因爲利息的存在，技術債
務不及時償還的話，會在未來呈現出非線性增長，造成始料不及的損失。
這裏的技術規劃包括如下幾點：
- 架構優化：一些結構不良、低內聚高耦合的代碼則會使得哪怕是微小的需求變
更或功能擴展都無從下手，修改的代價很可能超過了重寫的代價。同樣系統之
間的耦合也需要重點去關注，遵循微服務化的原則，系統也要遵循單一職責原
則，對於職責不清晰的系統去做解耦優化，進行一些模塊化改造、服務隔離、
公用服務抽象。 - 性能優化：基於財年對於業務量、數據量的發展評估，根據目前系統服務的
QPS\RT, 需要提前規劃對系統性能進行一些升級策略，包括重點關注對一些
慢接口、慢查詢的優化。 - 彈性與可靠性：系統提供的服務需要保障括數據一致性、冪等、防重攻擊，
同時也需要從熔斷降級、異地多活的角度去考慮存在哪些問題，目前系統的
SLA 指標是否能夠達到高可用，需要做哪些優化保障系統的高可用。 - 可伸縮：應用服務是否保證無狀態，關鍵節點發生故障能夠快速轉移、擴容，
避免故障擴大化。
總結
大家不知道有沒有類似的經歷，某個時間段突然一些線上故障頻發，各種技術
債、業務債被業務方窮追猛打要求還債，如果出現這種現象很大程度這個 TL 已經失
位了，這個團隊失控了。也曾經有人跟我吐槽他的 TL 把活都分給他們，而 TL 自己
什麼都不幹！這個技術 TL 真的什麼都不幹？曾經有一段時間我也在思考技術 TL 的
核心職責到底是什麼？技術 TL 應該具備哪些素質？
- 首先技術說到底是爲業務服務的，除非技術就是業務本身，必須體現它的商業價
值。在很多公司裏技術研發真的就成了實現其他部門需求的工具，我覺得這樣的技術
TL 肯定是不合格的。首先它不能影響業務發展，需求提出方會經過很多轉化，如果
不是不假思索傳遞需求，整個過程會失真。 - 第二個，我認爲最最重要的是架構設計的能力，可能管理能力還次之。對於管理
能力我認爲最重要的是對團隊的感知能力，因爲一旦到了技術 TL 這個級別，不能脫
離一線太遠，業務細節可以不清楚，大的方向必須要明確。如果沒有很細膩的感知能
力，很多的決策會有偏差。
如果他不是一個業務架構師，不是一個能給團隊指明更好方向的人，他最終會
淪爲一個需求翻譯器，產品經理說怎麼做就怎麼做。他更多的只是負責保證產品的質
量、開發的速度，最終被肢解成一個很瑣碎的人。一旦團隊上了一定的規模，團隊就
會從單純的需求實現走向團隊運營，而運營是需要方向的，業務架構就是一個基於運
營和數據的一種綜合的能力。
關於技術層面，技術 TL 需要具備如下素養：
- 技術視野良好，解決問題能力與架構設計能力出色。
技術 TL 要有良好的技術視野，不需要各種技術都樣樣精通，但是必須要所有涉
獵，有所瞭解，對各種技術領域的發展趨勢，主流非主流技術的應用場景要非常了
解。知道在什麼場景應用什麼技術，業務發展到什麼規模應該預先做哪些技術儲備。
產品架構的設計要有足夠的彈性，既能夠保證當前開發的高效率，又能夠對未來產品
架構的演進留出擴展的餘地。 - 動手能力要強，學習能力出色。
技術 TL 並不需要自己親自動手寫代碼，但是如有必要，自己可以隨時動手參與
第一線的編碼工作，技術 TL 不能長期遠離一線工作，自廢武功，紙上談兵。否則長
此以往，會對技術的判斷產生嚴重的失誤。另外，技術 TL 也應該是一個學習能力非
常出色的人，畢竟 IT 行業的技術更新換代速度非常快，如果沒有快速學習能力，是
沒有資格做好技術 TL 的。
技術 TL 除了管人和管事之外，其他還有很多事情要做包括建立團隊研發文化、
團隊人才培養與建設、跨部門協調與溝通等，這樣以要求技術 TL 也同時也需要具備
良好的溝通和管理能力，以上觀點僅是個人的一些思考和觀點，僅供參考。