如何成爲優秀的技術主管

「技術主管」是開發團隊中的某位程序員須要對一塊兒建立系統的整個開發團隊負責時所承擔的角色。一般他既要對最終交付的軟件系統負責，另外也會像一個程序員同樣去開發實現系統。

一個技術主管的 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,具體代碼以下： 

 

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必定要可以評估出從新審視產品和篩選需求的優先級，識別每個需求的必要性、重要性和實現成本。經過深思熟慮給團隊明確方向並專一，聚焦資源的支配，確保團隊的精力都聚焦在產品的核心需求上。

 

技術架構評審

 

互聯網時代，你們提倡敏捷迭代，總嫌傳統方式過重，流程複雜，影響效率，什麼都但願短平快，在扁平化的組織中，常常是需求火速分發到一線研發，而後就靠我的折騰去了，其實技術架構評審這一樣是一個很是重要的環節。架構評審或技術方案評審的價值在於集衆人的力量你們一塊兒來分析看看方案裏是否有坑，方案上線後是否會遇到不可逾越的重大技術問題，提早儘量把一些事情先考慮到提出質疑其實對項目的健康發展有很大的好處。

 

基於架構評審，咱們的目標核心是要知足如下幾點：

1.設計把關，確保方案合格，各方面都考慮到了，避免缺陷和遺漏，不求方案多牛，至少不犯錯。

2. 保證架構設計合理和基本一致，符合總體原則。

3. 維持對系統架構的全局認知，避免黑盒效應。

4. 經過評審發掘創新亮點，推廣最佳實踐。

 

架構設計既要保證架構設計的合理性和可擴展性，又要避免過分設計。架構設計不只僅是考慮功能實現，還有不少非功能需求，以及持續運維所須要的工做，須要工程實踐經驗，進行平衡和取捨。

架構評審須要如下幾點： 

1. 技術選型：爲何選用A組件不選用B、C組件，A是開源的，開源協議是啥？基於什麼語言開發的，出了問題咱們自身是否可以維護？性能方面有沒有壓測過？這些全部問題做爲技術選型咱們都須要考慮清楚，才能作最終決定。 

2. 高性能：產品對應的TPS、QPS和RT是多少？設計上會作到的TPS、QPS和RT是多少？而實際上咱們總體隨着數據量的增大系統性能會不會出現明顯問題？隨着業務量、數據量的上升，咱們的系統的性能如何去進一步提升？系統哪一個環節會是最大的瓶頸？是否有抗突發性能壓力的能力，大概能夠知足多少的TPS和QPS，怎麼去作來實現高性能，這些問題都須要咱們去思考。

3. 高可用：是否有單點的組件，非單點的組件如何作故障轉移？是否考慮過多活的方案？是否有數據丟失的可能性？數據丟失如何恢復？出現系統宕機狀況，對業務會形成哪些影響？有無其餘補救方案？這些問題須要想清楚，有相應的解決方案。

4. 可擴展性：A和B的業務策略相差無幾，後面會不會繼續衍生出C的業務策略，隨着業務的發展哪些環節能夠作擴展，如何作擴展？架構設計上須要考慮到業務的可擴展性。

5. 可伸縮性：每一個環節的服務是否是無狀態的？是否都是能夠快速橫向擴展的？擴容須要怎麼作手動仍是自動？擴展後是否能夠提升響應速度？這全部的問題都須要咱們去思考清楚，並有對應的解決方案。

6. 彈性處理：消息重複消費、接口重複調用對應的服務是否保證冪等？是否考慮了服務降級？哪些業務支持降級？支持自動降級仍是手工降級？是否考慮了服務的超時熔斷、異常熔斷、限流熔斷？觸發熔斷後對客戶的影響？服務是否作了隔離，單一服務故障是否影響全局？這些問題通通須要咱們想清楚對應的解決方案，纔會進一步保證架構設計的合理性 

7. 兼容性：上下游依賴是否梳理過，影響範圍多大？怎麼進行新老系統替換？新老系統可否來回切換？數據存儲是否兼容老的數據處理？若是對你的上下游系統有影響，是否通知到上下游業務方？上下游依賴方進行升級的方案成本如何最小化？這些問題須要有完美的解決方案，稍有不慎會致使故障。

8. 安全性：是否完全避免SQL注入和XSS？是否有數據泄露的可能性？是否作了風控策略？接口服務是否有防刷保護機制？數據、功能權限是否作了控制？小二後臺系統是否作了日誌審計？數據傳輸是否加密驗籤？應用代碼中是否有明文的AK/SK、密碼？這些安全細節問題須要咱們通通考慮清楚，安全問題任什麼時候候都不能輕視。

9. 可測性：測試環境和線上的差別多大？是否能夠在線上作壓測？線上壓測怎麼隔離測試數據？是否有測試白名單功能？是否支持部署多套隔離的測試環境？測試黑盒白盒工做量的比例是怎麼樣的？新的方案是否很是方便測試，在必定程度也須要考量。

10. 可運維性：系統是否有初始化或預熱的環節？數據是否指數級別遞增？業務數據是否須要按期歸檔處理？隨着時間的推移若是壓力保持不變的話系統須要怎麼來巡檢和維護？業務運維方面的設計也須要充分考慮到。

11. 監控與報警：對外部依賴的接口是否添加了監控與報警？應用層面系統內部是否有暴露了一些指標做監控和報警？系統層面使用的中間件和存儲是否有監控報警？只有充分考慮到各個環節的監控、報警，任何問題會第一時間通知到研發，阻止故障進一步擴散。

 

其實不一樣階段的項目有不一樣的目標，咱們不會在項目起步的時候作99.99%的可用性支持百萬QPS的架構，高效完成項目的業務目標也是架構考慮的因素之一。並且隨着項目的發展，隨着公司中間件和容器的標準化，不少架構的工做被標準化替代，業務代碼須要考慮架構方面伸縮性運維性等等的需求愈來愈少，慢慢的這些工做都能由架構和運維團隊來接。一開始的時候咱們能夠花一點時間來考慮這些問題，可是不是全部的問題都須要有最終的方案。

 

代碼評審 

代碼質量包括功能性代碼質量和非功能性代碼質量，功能質量大多經過測試可以去發現問題，非功能性代碼質量用戶不能直接體驗到這種質量的好壞，代碼質量很差，最直接的「受害者」是開發者或組織自身，由於代碼質量好壞直接決定了軟件的可維護性成本的高低。代碼質量應該更多的應該從可測性，可讀性，可理解性，容變性等代碼可維護性維度去衡量，其中 CodeReview 是保證代碼質量很是重要的一個環節，創建良好的 CodeReview 規範與習慣，對於一個技術團隊是一件很是重要核心的事情，沒有 CodeReview 的團隊沒有將來。

每次項目開發自測完成後，一般會組織該小組開發人員集體進行代碼 review，代碼 review 通常 review 代碼質量以及規範方面的問題，另外須要關注的是每一行代碼變動是否與本次需求相關，若是存在搭車發佈或者代碼重構優化，須要自行保證測試經過，不然不予發佈。

CodeReview 我會重點關注以下事情：

1. 確認代碼功能：代碼實現的功能知足產品需求，邏輯的嚴謹和合理性是最基本的要求。同時須要考慮適當的擴展性，在代碼的可擴展性和過分設計作出權衡，不編寫無用邏輯和一些與代碼功能無關的附加代碼。

在真正須要某些功能的時候纔去實現它，而不是你預見到它將會有用。 —— RonJeffries

2. 編碼規範：以集團開發規約、靜態代碼規約爲前提，是否遵照了編碼規範，遵循了最佳實踐。除了形式上的要求外，更重要的是命名規範。目標是提升代碼的可讀性，下降代碼可維護性成本。
3. 潛在的BUG：可能在最壞狀況下出現問題的代碼，包括常見的線程安全、業務邏輯準確性、系統邊界範圍、參數校驗，以及存在安全漏洞(業務鑑權、灰產可利用漏洞)的代碼。。
4. 文檔和註釋：過少（缺乏必要信息）、過多（沒有信息量）、過期的文檔或註釋，總之文檔和註釋要與時俱進，與最新代碼保持同步。其實不少時候我的以爲良好的變量、函數命名是最好的註釋，好的代碼賽過註釋。
5. 重複代碼：當一個項目在不斷開發迭代、功能累加的過程當中，重複代碼的出現幾乎是不可避免的，一般能夠經過PMD工具進行檢測。類型體系以外的重複代碼處理一般能夠封裝到對應的Util類或者Helper類中，類體系以內的重複代碼一般能夠經過繼承、模板模式等方法來解決。

6. 複雜度：代碼結構太複雜（如圈複雜度高），難以理解、測試和維護。
7. 監控與報警：基於產品的需求邏輯，須要有些指標來證實業務是正常work的，若是發生異常須要有監控、報警指標通知研發人員處理，review業務需求對應的監控與報警指標也是Code  Review的重點事項。
8. 測試覆蓋率：編寫單元測試，特別是針對複雜代碼的測試覆蓋是否足夠。

實際上維護單元測試的成本不比開發成本低，這點團隊目前作的的不到位。
針對以上每次代碼review所涉及到的經典案例會統一輸出到文檔裏，你們能夠共同窗習避免編寫出一樣的Ugly Code。

 

發佈計劃評審

涉及到10人日以上的項目，必須有明確的發佈計劃，並組織項目成員統一參加項目發佈計劃review，發佈計劃主要包含以下幾點： 

1）明確是否有外部依賴接口，若有請同步協調好業務方；

2）發佈前配置確認包括配置文件、數據庫配置、中間件配置等各類配置，尤爲各類環境下的差別化配置項；

3）二方庫發佈順序，是否有依賴；

4）應用發佈順序；

5）數據庫是否有數據變動和訂正，以及表結構調整；

6）回滾計劃，必需要有回滾計劃，發佈出現問題要有緊急回滾策略；

7）生產環境迴歸測試重點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也同時也須要具有良好的溝通和管理能力，以上觀點僅是我的的一些思考和觀點，僅供參考。