技術(shù)主管椅寺，又叫技術(shù)經(jīng)理，英文一般是 Tech Leader 蒋失，簡稱 TL返帕。隨著工作經(jīng)驗的不斷積累，能力的不斷提升篙挽，每個人都有機會成為 Team Leader荆萤。

然而在機會到來前，我們必須提前做好準(zhǔn)備铣卡，對 TL 的工作職責(zé)有一定了解链韭。當(dāng)然，這也會為當(dāng)下更好地配合 TL 工作打下基礎(chǔ)煮落。我們來從以下三點探討一下：

開發(fā)規(guī)范

開發(fā)流程

技術(shù)規(guī)劃與管理

技術(shù)主管是開發(fā)團隊中的某位程序員需要對一起創(chuàng)建系統(tǒng)的整個開發(fā)團隊負(fù)責(zé)時所承擔(dān)的角色敞峭。

通常他既要對最終交付的軟件系統(tǒng)負(fù)責(zé)，另外也會像一個程序員一樣去開發(fā)實現(xiàn)系統(tǒng)蝉仇。

一個技術(shù)主管的 60%～70% 的時間可能花在了開發(fā)任務(wù)分解分配旋讹、開發(fā)實踐、技術(shù)架構(gòu)評審量淌、代碼審核和風(fēng)險識別上骗村。

而余下的 30%～40% 的時間則花在為了保障系統(tǒng)按時交付所需的各種計劃嫌褪、協(xié)作呀枢、溝通、管理上笼痛。

和團隊管理者不同的是裙秋，技術(shù)主管的大部分管理工作都是針對具體研發(fā)任務(wù)和技術(shù)事務(wù)的琅拌。

開發(fā)規(guī)范

開發(fā)規(guī)范可以說是我來到這個團隊干的第一件事，我當(dāng)時面對的問題是 API 接口格式混亂摘刑，沒有標(biāo)準(zhǔn)的 RPC 服務(wù)化进宝，代碼沒有統(tǒng)一標(biāo)準(zhǔn)的開發(fā)規(guī)范，技術(shù)框架組件非標(biāo)準(zhǔn)化等一系列問題枷恕。

作為一名業(yè)務(wù)上的新人党晋，我第一時間制定了一套相對標(biāo)準(zhǔn)、全面的技術(shù)開發(fā)規(guī)范徐块，邊寫代碼邊梳理開發(fā)規(guī)范未玻，引領(lǐng)團隊走向統(tǒng)一標(biāo)準(zhǔn)化開發(fā)道路。

針對團隊研發(fā)規(guī)范暴露的上述問題胡控，主要制定了如下規(guī)范：

命名規(guī)范

我自己非常注重搭建項目結(jié)構(gòu)的起步過程扳剿，應(yīng)用命名規(guī)范、模塊的劃分昼激、目錄（包）的命名庇绽，我覺得非常重要，如果做的足夠好橙困，別人導(dǎo)入項目后可能只需要 10 分鐘就可以大概了解系統(tǒng)結(jié)構(gòu)瞧掺。

具體規(guī)范包括包命名、類的命名凡傅、接口命名夸盟、方法命名、變量命名像捶、常量命名上陕。

統(tǒng)一 IDE 代碼模板

約定了 IDEA/Eclipse IDE 代碼的統(tǒng)一模板，代碼風(fēng)格一定要統(tǒng)一拓春，避免不同開發(fā)人員使用不同模板帶來的差異化以及代碼 merge 成本释簿。

使用 IDEA 的同學(xué)可以安裝 Eclipse Code Formatter 插件，和 Eclipse 統(tǒng)一代碼模板硼莽。

Maven 使用規(guī)范

所有二方庫庶溶、三方庫的版本統(tǒng)一定義到 parent pom 里，這樣所有業(yè)務(wù)應(yīng)用工程統(tǒng)一繼承 parent pom 里所指定的二方庫懂鸵、三方庫的版本偏螺，統(tǒng)一框架與工具的版本(Spring、Apache commons 工具類匆光、日志組件套像、JSON 處理、數(shù)據(jù)庫連接池等)终息，同時要求生產(chǎn)環(huán)境禁用 SNAPSHOT 版本夺巩。

這樣一來升級通用框架與工具的版本贞让，只需要應(yīng)用工程升級 parent pom 即可。

代碼 Commit 規(guī)范

基于 Angular Commit Message 規(guī)范生成統(tǒng)一的 ChangeLog柳譬。

這樣對于每次發(fā)布 release tag 非常清晰喳张，Mac 下都需要安裝對應(yīng)的插件，IDEA 也有對應(yīng)的插件美澳，具體可以參考阮一峰老師的《Commit message 和 Change log 編寫指南》销部。

此刻忽然想起 Linus 面對 pull request 里的騷操作所發(fā)的飚：

Get rid of it. And I don’t ever want to see that shit again.?

——Linus

代碼的 Commit 的規(guī)范對團隊非常重要，清晰的 Commit 信息生成的 release tag制跟，對于生產(chǎn)環(huán)境的故障回滾業(yè)非常關(guān)鍵柴墩，能夠提供一些有價值的信息。

統(tǒng)一 API 規(guī)范

統(tǒng)一 RPC 服務(wù)接口的返回值 ResultDTO凫岖，具體代碼如下：

Success 代表接口處理響應(yīng)結(jié)果成功還是失敗江咳，errorCode、errorMsg 表示返回錯誤碼和錯誤消息哥放。

Module 表示返回結(jié)果集歼指，把 ResultDTO 定義到 common-api 頂層二方庫，這樣以來各個應(yīng)用不需要來回轉(zhuǎn)換返回結(jié)果甥雕。

Http Rest 接口規(guī)范約定同 ResultDTO 相差無幾踩身，需要額外關(guān)注一下加解密規(guī)范和簽名規(guī)范、版本管理規(guī)范社露。

異常處理規(guī)范

異常處理不僅僅是狹義上遇到了 Exception 怎么去處理挟阻，還有各種業(yè)務(wù)邏輯遇到錯誤的時候我們怎么去處理。

Service 服務(wù)層捕獲的異常主要包括 BusinessException(業(yè)務(wù)異常)峭弟、RetriableException (可重試異常) 到 common-api附鸽，定義一個公共異常攔截器，對業(yè)務(wù)異常瞒瘸、重試異常進行統(tǒng)一處理坷备，對于可重試的異常調(diào)用的服務(wù)接口需要保證其冪等性。

另外其他業(yè)務(wù)層有些特殊異常不需要攔截器統(tǒng)一處理情臭，內(nèi)部可以進行自我消化處理掉省撑。

根據(jù)場景對應(yīng)的處理原則主要包括：

直接返回

拋出異常

重試處理

熔斷處理

降級處理

這又涉及到了彈力設(shè)計的話題，我們的系統(tǒng)往往會對接各種依賴外部服務(wù)俯在、API竟秫，大部分服務(wù)都不會有 SLA，即使有在大并發(fā)下我們也需要考慮外部服務(wù)不可用對自己的影響跷乐，會不會把自己拖死肥败。

我們總是希望：

盡可能以小的代價通過嘗試讓業(yè)務(wù)可以完成。

如果外部服務(wù)基本不可用，而我們又同步調(diào)用外部服務(wù)的話拙吉，我們需要進行自我保護直接熔斷潮孽，否則在持續(xù)的并發(fā)的情況下自己就會垮了揪荣。

如果外部服務(wù)特別重要筷黔，我們往往會考慮引入多個同類型的服務(wù)，根據(jù)價格仗颈、服務(wù)標(biāo)準(zhǔn)做路由佛舱，在出現(xiàn)問題的時候自動降級。

推薦使用 Netflix 開源的 Hystrix 容災(zāi)框架挨决，主要解決當(dāng)外部依賴出現(xiàn)故障時拖垮業(yè)務(wù)系統(tǒng)请祖、甚至引起雪崩的問題。

目前我團隊也在使用脖祈，能夠很好的解決異常熔斷肆捕、超時熔斷、基于并發(fā)數(shù)限流熔斷的降級處理盖高。

分支開發(fā)規(guī)范

早期的時候源碼的版本管理基于 SVN慎陵，后來逐步切換到 Git，分支如何管理每一個公司（在 Gitflow 的基礎(chǔ)上）都會略有不同喻奥。

針對分支開發(fā)規(guī)范席纽，指定如下標(biāo)準(zhǔn)：

分支的定義（master、develop撞蚕、release润梯、hotfix、feature）

分支命名規(guī)范

Checkout甥厦、merge request 流程

提測流程

上線流程

Hotfix 流程

雖然這個和代碼質(zhì)量和架構(gòu)無關(guān)纺铭，按照這一套標(biāo)準(zhǔn)執(zhí)行下來，能夠給整個研發(fā)團隊帶領(lǐng)很大的便利：

減少甚至杜絕代碼管理導(dǎo)致的線上事故刀疙。

提高開發(fā)和測試的工作效率辐烂，人多也亂。

減少甚至杜絕代碼管理導(dǎo)致的線上事故医寿。

方便運維處理發(fā)布和回滾巡揍。

讓項目的開發(fā)可以靈活適應(yīng)多變的需求，多人協(xié)同開發(fā)油够。

統(tǒng)一日志規(guī)范

日志是產(chǎn)品必不可少的一個功能蚁袭，具備可回溯性、能夠抓取問題現(xiàn)場信息是其獨一無二的優(yōu)點石咬，尤其在生產(chǎn)系統(tǒng)上問題定位等方面具有不可替代的作用揩悄。

這里著重強調(diào)一下針對異常的日志規(guī)范：

WARN 和 ERROR 的選擇需要好好考慮，WARN 一般我傾向于記錄可自恢復(fù)但值得關(guān)注的錯誤鬼悠，ERROR 代表了不能自己恢復(fù)的錯誤删性。

對于業(yè)務(wù)處理遇到問題用 ERROR 不合理亏娜，對于 Catch 到了異常也不是全用 ERROR。

記錄哪些信息蹬挺，最好打印一定的上下文（鏈路 TraceId维贺、用戶 Id、訂單 Id巴帮、外部傳來的關(guān)鍵數(shù)據(jù)）而不僅僅是打印線程棧溯泣。

記錄了上下文信息，是否要考慮日志脫敏問題榕茧？可以在框架層面實現(xiàn)垃沦，比如自定義實現(xiàn) Logback 的 ClassicConverter。

正確合理的使用日志用押，能夠指引開發(fā)人員快速查找錯誤肢簿、定位問題，因此約定了一套日志使用標(biāo)準(zhǔn)規(guī)范蜻拨，現(xiàn)在可以更多的參考《阿里經(jīng)濟體開發(fā)規(guī)約——日志規(guī)約》池充。

統(tǒng)一 MySQL 開發(fā)規(guī)范

表的設(shè)計和 API 的定義類似，屬于那種開頭沒有開好官觅，以后改變需要花 10x 代價的纵菌，我知道，一開始在業(yè)務(wù)不明確的情況下休涤，設(shè)計出良好的一步到位的表結(jié)構(gòu)很困難咱圆，但是至少我們可以做的是有一個好的標(biāo)準(zhǔn)。

統(tǒng)一工具與框架

對開發(fā)過程中所用到的公共組件進行了統(tǒng)一抽象與封裝功氨，包括 Dao 層框架 Mybatis序苏、Cache 組件 Jetcache、Httpclient 組件捷凄、Common-tools (公共工具)忱详，同時抽取出全局唯一 ID、分布式鎖跺涤、冪等等公共組件匈睁。

把以上公共組件進行集成到各個應(yīng)用，進行統(tǒng)一升級桶错、維護航唆，這樣以來方便大家將更多的精力集中到業(yè)務(wù)開發(fā)上。

開發(fā)流程

目前團隊的開發(fā)模式還是基于傳統(tǒng)的瀑布開發(fā)模式院刁，整體開發(fā)流程涉及需求評審糯钙、測試用例評審、技術(shù)架構(gòu)評審、開發(fā)與測試任岸、驗收與上線再榄。

這里主要基于 TL 的角度從需求管理、技術(shù)架構(gòu)評審享潜、代碼評審困鸥、發(fā)布計劃評審幾個關(guān)鍵重點環(huán)節(jié)進行探討，歡迎拍磚米碰。

需求管理

美國專門從事跟蹤 IT 項目成功或失敗的權(quán)威機構(gòu) Standish Group 的 CHAOS Reports 報導(dǎo)了該公司的一項研究窝革，該公司對多個項目作調(diào)查后發(fā)現(xiàn)购城，百分之七十四的項目是失敗的吕座，即這些項目不能按時按預(yù)算完成。

其中提到最多的導(dǎo)致項目失敗的原因就是"變更用戶需求"瘪板。另外從歷年的 Standish Group 報告分析看吴趴，導(dǎo)致項目失敗的最重要原因與需求有關(guān)。

Standish Group 的 CHAOS 報告進一步證實了與成功項目最密切的因素是良好的需求管理侮攀，也就是項目的范圍管理锣枝，特別是管理好項目的變更。

產(chǎn)品因需求而生兰英，在產(chǎn)品的整個生命周期中撇叁，產(chǎn)品經(jīng)理會收到來自各個方面的需求。

但是每一個需求的必要性畦贸、重要性和實現(xiàn)成本都需要經(jīng)過深思熟慮的分析和計劃陨闹，避免盲目的決定需求或者變更需求。

這樣很容易導(dǎo)致工作混亂薄坏，技術(shù) TL 如果不能正確的對需求進行把控趋厉，會導(dǎo)致整個項目偏離正確的軌道。

需求管理的第一步就是要梳理不同來源的需求胶坠，主要包括從產(chǎn)品定位出發(fā)君账、外部用戶反饋、競爭對手情況沈善、市場變化以及內(nèi)部運營人員乡数、客服人員、開發(fā)人員的反饋闻牡。

首先技術(shù) TL 對產(chǎn)品有足夠認(rèn)知和把控净赴，簡單來說就是我的產(chǎn)品是為了滿足哪些人的哪些需求而做，產(chǎn)品需求一定要根植于客戶的需求澈侠、根植于客戶的環(huán)境劫侧。

每款產(chǎn)品必定有其核心價值，能夠為客戶創(chuàng)造更多的價值，基于此考慮往往能得到一些核心需求烧栋，摒除價值不大的需求写妥。

需求管理中最重要的就是對發(fā)散性需求的管理，往往因此也會導(dǎo)致產(chǎn)品在執(zhí)行過程中不斷的變更或增加需求审姓。

由于人的思維是發(fā)散性的珍特，所以往往在產(chǎn)品構(gòu)思的過程中會出現(xiàn)各種新鮮好玩的想法，這些想法可能來自領(lǐng)導(dǎo)或者產(chǎn)品經(jīng)理自己魔吐，但是這些想法往往都是和產(chǎn)品核心方向不相關(guān)的扎筒。

由于這些想法能夠在當(dāng)時帶來誘惑，因此這些不相關(guān)的需求會嚴(yán)重干擾技術(shù)團隊的精力酬姆，打亂或者延誤產(chǎn)品原本的計劃嗜桌。

同樣技術(shù)研發(fā)同學(xué)也需要建立對產(chǎn)品的深度思考，不要把自己定位成產(chǎn)品需求的實現(xiàn)者辞色，同樣需要對需求負(fù)責(zé)骨宠。

很多時候需求的變更或增加是因為我們面臨太多選擇和想要的太多，沒有適當(dāng)?shù)目刂谱约旱挠嗦⒁宰约旱南埠脕頉Q定需求层亿，這些因素很容易導(dǎo)致產(chǎn)品沒有明確的方向、團隊成員疲于奔命立美，但是卻沒有實際的成果匿又。

所以技術(shù) TL 一定要能夠評估出重新審視產(chǎn)品和篩選需求的優(yōu)先級，識別每一個需求的必要性建蹄、重要性和實現(xiàn)成本碌更。

通過深思熟慮給團隊明確方向并專注，聚焦資源的支配躲撰，確保團隊的精力都聚焦在產(chǎn)品的核心需求上针贬。

技術(shù)架構(gòu)評審

互聯(lián)網(wǎng)時代，大家提倡敏捷迭代拢蛋，總嫌傳統(tǒng)方式太重桦他，流程復(fù)雜，影響效率谆棱，什么都希望短平快快压。

在扁平化的組織中，經(jīng)常是需求火速分發(fā)到一線研發(fā)垃瞧，然后就靠個人折騰去了蔫劣，其實技術(shù)架構(gòu)評審這同樣是一個非常重要的環(huán)節(jié)。

架構(gòu)評審或技術(shù)方案評審的價值在于集眾人的力量大家一起來分析看看方案里是否有坑个从，方案上線后是否會遇到不可逾越的重大技術(shù)問題脉幢，提前盡可能把一些事情先考慮到，提出質(zhì)疑其實對項目的健康發(fā)展有很大的好處嫌松。

基于架構(gòu)評審沪曙，我們的目標(biāo)核心是要滿足以下幾點：

設(shè)計把關(guān)萎羔，確保方案合格液走，各方面都考慮到了，避免缺陷和遺漏贾陷，不求方案多牛缘眶，至少不犯錯。

保證架構(gòu)設(shè)計合理和基本一致髓废，符合整體原則巷懈。

維持對系統(tǒng)架構(gòu)的全局認(rèn)知，避免黑盒效應(yīng)瓦哎。

通過評審發(fā)掘創(chuàng)新亮點砸喻，推廣最佳實踐柔逼。

架構(gòu)設(shè)計既要保證架構(gòu)設(shè)計的合理性和可擴展性蒋譬，又要避免過度設(shè)計。架構(gòu)設(shè)計不僅僅是考慮功能實現(xiàn)愉适，還有很多非功能需求犯助，以及持續(xù)運維所需要的工作，需要工程實踐經(jīng)驗维咸，進行平衡和取舍剂买。

架構(gòu)評審需要以下幾點：

技術(shù)選型

為什么選用 A 組件不選用 B、C 組件癌蓖，A 是開源的瞬哼，開源協(xié)議是啥？基于什么語言開發(fā)的租副，出了問題我們自身是否能夠維護坐慰？性能方面有沒有壓測過？

這些所有問題作為技術(shù)選型我們都需要考慮清楚用僧，才能做最終決定结胀。

高性能

產(chǎn)品對應(yīng)的 TPS、QPS 和 RT 是多少责循？設(shè)計上會做到的 TPS糟港、QPS 和 RT 是多少？而實際上我們整體隨著數(shù)據(jù)量的增大系統(tǒng)性能會不會出現(xiàn)明顯問題院仿？

隨著業(yè)務(wù)量秸抚、數(shù)據(jù)量的上升速和，我們的系統(tǒng)的性能如何去進一步提高？系統(tǒng)哪個環(huán)節(jié)會是最大的瓶頸剥汤？

是否有抗突發(fā)性能壓力的能力健芭，大概可以滿足多少的 TPS 和 QPS，怎么去做來實現(xiàn)高性能秀姐，這些問題都需要我們?nèi)ニ伎肌?/p>

高可用

是否有單點的組件慈迈，非單點的組件如何做故障轉(zhuǎn)移？是否考慮過多活的方案省有？是否有數(shù)據(jù)丟失的可能性痒留？數(shù)據(jù)丟失如何恢復(fù)？

出現(xiàn)系統(tǒng)宕機情況蠢沿，對業(yè)務(wù)會造成哪些影響伸头？有無其他補救方案？這些問題需要想清楚舷蟀，有相應(yīng)的解決方案恤磷。

可擴展性

A 和 B 的業(yè)務(wù)策略相差無幾，后面會不會繼續(xù)衍生出 C 的業(yè)務(wù)策略野宜，隨著業(yè)務(wù)的發(fā)展哪些環(huán)節(jié)可以做擴展扫步，如何做擴展？架構(gòu)設(shè)計上需要考慮到業(yè)務(wù)的可擴展性匈子。

可伸縮性

每個環(huán)節(jié)的服務(wù)是不是無狀態(tài)的河胎？是否都是可以快速橫向擴展的？擴容需要怎么做虎敦，手動還是自動游岳？擴展后是否可以提高響應(yīng)速度？

這所有的問題都需要我們?nèi)ニ伎记宄溽悖⒂袑?yīng)的解決方案胚迫。

彈性處理

消息重復(fù)消費、接口重復(fù)調(diào)用對應(yīng)的服務(wù)是否保證冪等唾那？是否考慮了服務(wù)降級访锻？哪些業(yè)務(wù)支持降級？支持自動降級還是手工降級通贞？

是否考慮了服務(wù)的超時熔斷朗若、異常熔斷、限流熔斷昌罩？觸發(fā)熔斷后對客戶的影響哭懈？服務(wù)是否做了隔離，單一服務(wù)故障是否影響全局茎用？

這些問題統(tǒng)統(tǒng)需要我們想清楚對應(yīng)的解決方案遣总，才會進一步保證架構(gòu)設(shè)計的合理性睬罗。

兼容性

上下游依賴是否梳理過，影響范圍多大旭斥？怎么進行新老系統(tǒng)替換容达？新老系統(tǒng)能否來回切換？數(shù)據(jù)存儲是否兼容老的數(shù)據(jù)處理垂券？

如果對你的上下游系統(tǒng)有影響花盐，是否通知到上下游業(yè)務(wù)方？上下游依賴方進行升級的方案成本如何最小化菇爪？

這些問題需要有完美的解決方案算芯，稍有不慎會導(dǎo)致故障。

安全性

是否徹底避免 SQL 注入和 XSS凳宙？是否有數(shù)據(jù)泄露的可能性熙揍？是否做了風(fēng)控策略？接口服務(wù)是否有防刷保護機制氏涩？

數(shù)據(jù)届囚、功能權(quán)限是否做了控制？小二后臺系統(tǒng)是否做了日志審計是尖？數(shù)據(jù)傳輸是否加密驗簽意系？應(yīng)用代碼中是否有明文的 AK/SK、密碼析砸？

這些安全細(xì)節(jié)問題需要我們統(tǒng)統(tǒng)考慮清楚昔字，安全問題任何時候都不能輕視。

可測性

測試環(huán)境和線上的差異多大首繁？是否可以在線上做壓測？線上壓測怎么隔離測試數(shù)據(jù)陨囊？是否有測試白名單功能弦疮？是否支持部署多套隔離的測試環(huán)境？

測試黑盒白盒工作量的比例是怎么樣的蜘醋？新的方案是否非常方便測試胁塞，在一定程度也需要考量。

可運維性

系統(tǒng)是否有初始化或預(yù)熱的環(huán)節(jié)压语？數(shù)據(jù)是否指數(shù)級別遞增啸罢？業(yè)務(wù)數(shù)據(jù)是否需要定期歸檔處理？

隨著時間的推移胎食，如果壓力保持不變的話扰才，系統(tǒng)需要怎么來巡檢和維護？業(yè)務(wù)運維方面的設(shè)計也需要充分考慮到厕怜。

監(jiān)控與報警

對外部依賴的接口是否添加了監(jiān)控與報警衩匣？應(yīng)用層面系統(tǒng)內(nèi)部是否又暴露了一些指標(biāo)作監(jiān)控和報警蕾总？系統(tǒng)層面使用的中間件和存儲是否有監(jiān)控報警？

只有充分考慮到各個環(huán)節(jié)的監(jiān)控琅捏、報警生百，任何問題會第一時間通知到研發(fā)，才能阻止故障進一步擴散柄延。

其實不同階段的項目有不同的目標(biāo)蚀浆，我們不會在項目起步的時候做 99.99% 的可用性支持百萬 QPS 的架構(gòu)，高效完成項目的業(yè)務(wù)目標(biāo)也是架構(gòu)考慮的因素之一搜吧。

而且隨著項目的發(fā)展蜡坊，隨著公司中間件和容器的標(biāo)準(zhǔn)化，很多架構(gòu)的工作被標(biāo)準(zhǔn)化替代赎败，業(yè)務(wù)代碼需要考慮架構(gòu)方面伸縮性秕衙、運維性等等的需求越來越少，慢慢的這些工作都能由架構(gòu)和運維團隊來接僵刮。

一開始的時候我們可以花一點時間來考慮這些問題据忘，但是不是所有的問題都需要有最終的方案。

代碼評審

代碼質(zhì)量包括功能性代碼質(zhì)量和非功能性代碼質(zhì)量搞糕，功能質(zhì)量大多通過測試能夠去發(fā)現(xiàn)問題勇吊，非功能性代碼質(zhì)量用戶不能直接體驗到這種質(zhì)量的好壞。

代碼質(zhì)量不好窍仰，最直接的“受害者”是開發(fā)者或組織自身汉规，因為代碼質(zhì)量好壞直接決定了軟件的可維護性成本的高低。

代碼質(zhì)量應(yīng)該更多的從可測性驹吮，可讀性针史，可理解性，容變性等代碼可維護性維度去衡量碟狞。

其中 CodeReview 是保證代碼質(zhì)量非常重要的一個環(huán)節(jié)啄枕，建立良好的 CodeReview 規(guī)范與習(xí)慣，對于一個技術(shù)團隊是一件非常重要核心的事情族沃，沒有 CodeReview 的團隊沒有未來频祝。

每次項目開發(fā)自測完成后，通常會組織該小組開發(fā)人員集體進行代碼 review脆淹，代碼 review 一般 review 代碼質(zhì)量以及規(guī)范方面的問題常空。

另外需要關(guān)注的是每一行代碼變更是否與本次需求相關(guān)，如果存在搭車發(fā)布或者代碼重構(gòu)優(yōu)化盖溺，需要自行保證測試通過漓糙，否則不予發(fā)布。

CodeReview 我會重點關(guān)注如下事情：

①確認(rèn)代碼功能：代碼實現(xiàn)的功能滿足產(chǎn)品需求咐柜，邏輯的嚴(yán)謹(jǐn)和合理性是最基本的要求兼蜈。

同時需要考慮適當(dāng)?shù)臄U展性攘残，在代碼的可擴展性和過度設(shè)計做出權(quán)衡，不編寫無用邏輯和一些與代碼功能無關(guān)的附加代碼为狸。

在真正需要某些功能的時候才去實現(xiàn)它歼郭，而不是你預(yù)見到它將會有用。?

—— RonJeffries

②編碼規(guī)范：以集團開發(fā)規(guī)約辐棒、靜態(tài)代碼規(guī)約為前提病曾，是否遵守了編碼規(guī)范，遵循了最佳實踐漾根。

除了形式上的要求外泰涂，更重要的是命名規(guī)范。目標(biāo)是提高代碼的可讀性辐怕，降低代碼可維護性成本逼蒙。

③潛在的 Bug：可能在最壞情況下出現(xiàn)問題的代碼，包括常見的線程安全寄疏、業(yè)務(wù)邏輯準(zhǔn)確性是牢、系統(tǒng)邊界范圍、參數(shù)校驗陕截，以及存在安全漏洞(業(yè)務(wù)鑒權(quán)驳棱、灰產(chǎn)可利用漏洞)的代碼。

④文檔和注釋：過少（缺少必要信息）农曲、過多（沒有信息量）社搅、過時的文檔或注釋，總之文檔和注釋要與時俱進乳规，與最新代碼保持同步形葬。

其實很多時候個人覺得良好的變量、函數(shù)命名是最好的注釋驯妄，好的代碼勝過注釋荷并。

⑤重復(fù)代碼：當(dāng)一個項目在不斷開發(fā)迭代、功能累加的過程中青扔，重復(fù)代碼的出現(xiàn)幾乎是不可避免的，通臭嫖保可以通過 PMD 工具進行檢測微猖。

類型體系之外的重復(fù)代碼處理通常可以封裝到對應(yīng)的 Util 類或者 Helper 類中缘屹，類體系之內(nèi)的重復(fù)代碼通沉莅可以通過繼承、模板模式等方法來解決轻姿。

⑥復(fù)雜度：代碼結(jié)構(gòu)太復(fù)雜（如圈復(fù)雜度高）犁珠，難以理解逻炊、測試和維護。

⑦監(jiān)控與報警：基于產(chǎn)品的需求邏輯犁享，需要有些指標(biāo)來證明業(yè)務(wù)是正常 work 的余素，如果發(fā)生異常需要有監(jiān)控、報警指標(biāo)通知研發(fā)人員處理炊昆，review 業(yè)務(wù)需求對應(yīng)的監(jiān)控與報警指標(biāo)也是 CodeReview 的重點事項桨吊。

⑧測試覆蓋率：編寫單元測試，特別是針對復(fù)雜代碼的測試覆蓋是否足夠凤巨。

實際上維護單元測試的成本不比開發(fā)成本低视乐，這點團隊目前做的的不到位。

針對以上每次代碼 review 所涉及到的經(jīng)典案例會統(tǒng)一輸出到文檔里敢茁，大家可以共同學(xué)習(xí)避免編寫出同樣的 Ugly Code佑淀。

發(fā)布計劃評審

涉及到 10 人日以上的項目，必須有明確的發(fā)布計劃彰檬，并組織項目成員統(tǒng)一參加項目發(fā)布計劃 review伸刃。

發(fā)布計劃主要包含如下幾點：

明確是否有外部依賴接口，如有請同步協(xié)調(diào)好業(yè)務(wù)方僧叉。

發(fā)布前配置確認(rèn)包括配置文件奕枝、數(shù)據(jù)庫配置、中間件配置等各種配置瓶堕，尤其各種環(huán)境下的差異化配置項隘道。

二方庫發(fā)布順序，是否有依賴郎笆。

應(yīng)用發(fā)布順序谭梗。

數(shù)據(jù)庫是否有數(shù)據(jù)變更和訂正，以及表結(jié)構(gòu)調(diào)整宛蚓。

回滾計劃激捏，必須要有回滾計劃，發(fā)布出現(xiàn)問題要有緊急回滾策略凄吏。

生產(chǎn)環(huán)境回歸測試重點 Case远舅。

技術(shù)規(guī)劃與管理

我在帶技術(shù)團隊的這些年，對團隊一直有一個要求痕钢，每周都要做系統(tǒng)健康度巡檢图柏，未雨綢繆、晴天修屋頂任连，避免在極端場景下某些隱藏的 Bug 轉(zhuǎn)變成了故障蚤吹。

系統(tǒng)健康度巡檢

為什么要把系統(tǒng)健康度巡檢放到技術(shù)管理里，我覺得這是一個非常重要的環(huán)節(jié)。

像傳統(tǒng)的航空裁着、電力繁涂、汽車行業(yè)都要有一定的巡檢機制，保障設(shè)備系統(tǒng)正常運轉(zhuǎn)二驰，同樣軟件系統(tǒng)也同樣需要巡檢機制保障業(yè)務(wù)健康發(fā)展扔罪。

隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)量和數(shù)據(jù)量不斷的上漲诸蚕，系統(tǒng)架構(gòu)的腐蝕是避免不了的步势，為了保障系統(tǒng)的健康度，需要不斷的考慮對系統(tǒng)架構(gòu)背犯、性能進行優(yōu)化坏瘩。

系統(tǒng)的監(jiān)控與報警能夠一定程度發(fā)現(xiàn)系統(tǒng)存在的問題，系統(tǒng)存在的一些隱患需要通過對系統(tǒng)的巡檢去發(fā)現(xiàn)漠魏，如果優(yōu)化不及時在極端情況會導(dǎo)致故障倔矾，巡檢粒度建議每周巡檢一次自己所負(fù)責(zé)的業(yè)務(wù)系統(tǒng)。

系統(tǒng)巡檢重點要關(guān)注如下幾點：

系統(tǒng)指標(biāo)：系統(tǒng) CPU柱锹、負(fù)載哪自、內(nèi)存、網(wǎng)絡(luò)禁熏、磁盤有無異常情況波動壤巷，確認(rèn)是否由發(fā)布導(dǎo)致，還是系統(tǒng)調(diào)用異常瞧毙。

慢接口：通常 RT 大于 3s 的接口需要重點關(guān)注胧华，極端并發(fā)場景下容易導(dǎo)致整個系統(tǒng)雪崩。

慢查詢：MySQL 慢查詢需要重點關(guān)注宙彪，隨著數(shù)據(jù)量上漲矩动，需要對慢查詢進行優(yōu)化。

錯誤日志：通過錯誤日志去發(fā)現(xiàn)系統(tǒng)隱藏的一些 Bug释漆，避免這些 Bug 被放大悲没，甚至極端情況下會導(dǎo)致故障。

技術(shù)規(guī)劃

技術(shù)規(guī)劃通常由團隊的 TL 負(fù)責(zé)男图，每個財年 TL 需要從大局的角度去思考每個季度的技術(shù)優(yōu)化規(guī)劃示姿，去償還技術(shù)債。

技術(shù)債也是有利息的逊笆，因為利息的存在峻凫，技術(shù)債務(wù)不及時償還的話，會在未來呈現(xiàn)出非線性增長览露，造成始料不及的損失。

這里的技術(shù)規(guī)劃包括如下幾點：

①架構(gòu)優(yōu)化：一些結(jié)構(gòu)不良譬胎、低內(nèi)聚高耦合的代碼則會使得哪怕是微小的需求變更或功能擴展都無從下手差牛，修改的代價很可能超過了重寫的代價命锄。

同樣系統(tǒng)之間的耦合也需要重點去關(guān)注，遵循微服務(wù)化的原則偏化，系統(tǒng)也要遵循單一職責(zé)原則脐恩，對于職責(zé)不清晰的系統(tǒng)去做解耦優(yōu)化，進行一些模塊化改造侦讨、服務(wù)隔離驶冒、公用服務(wù)抽象。

②性能優(yōu)化：基于財年對于業(yè)務(wù)量韵卤、數(shù)據(jù)量的發(fā)展評估骗污，根據(jù)目前系統(tǒng)服務(wù)的 QPS\RT，需要提前規(guī)劃對系統(tǒng)性能進行一些升級策略沈条，包括重點關(guān)注對一些慢接口需忿、慢查詢的優(yōu)化。

③彈性與可靠性：系統(tǒng)提供的服務(wù)需要保障數(shù)據(jù)一致性蜡歹、冪等屋厘、防重攻擊，同時也需要從熔斷降級月而、異地多活的角度去考慮存在哪些問題汗洒，目前系統(tǒng)的SLA指標(biāo)是否能夠達到高可用，需要做哪些優(yōu)化保障系統(tǒng)的高可用父款。

④可伸縮：應(yīng)用服務(wù)是否保證無狀態(tài)溢谤，關(guān)鍵節(jié)點發(fā)生故障能夠快速轉(zhuǎn)移、擴容铛漓，避免故障擴大化溯香。

總結(jié)

大家不知道有沒有類似的經(jīng)歷，某個時間段突然一些線上故障頻發(fā)浓恶，各種技術(shù)債玫坛、業(yè)務(wù)債被業(yè)務(wù)方窮追猛打要求還債，如果出現(xiàn)這種現(xiàn)象很大程度這個 TL 已經(jīng)失位了包晰，這個團隊失控了湿镀。

也曾經(jīng)有人跟我吐槽他的 TL 把活都分給他們，而 TL 自己什么都不干伐憾！這個技術(shù) TL 真的什么都不干勉痴？

曾經(jīng)有一段時間我也在思考技術(shù) TL 的核心職責(zé)到底是什么？技術(shù) TL 應(yīng)該具備哪些素質(zhì)树肃？

首先技術(shù)說到底是為業(yè)務(wù)服務(wù)的蒸矛，除非技術(shù)就是業(yè)務(wù)本身，必須體現(xiàn)它的商業(yè)價值。

在很多公司里技術(shù)研發(fā)真的就成了實現(xiàn)其他部門需求的工具雏掠，我覺得這樣的技術(shù) TL 肯定是不合格的斩祭。

首先它不能影響業(yè)務(wù)發(fā)展，需求提出方會經(jīng)過很多轉(zhuǎn)化乡话，如果不是不假思索傳遞需求摧玫，整個過程會失真。

第二個绑青，我認(rèn)為最最重要的是架構(gòu)設(shè)計的能力诬像，可能管理能力還次之。對于管理能力我認(rèn)為最重要的是對團隊的感知能力闸婴。

因為一旦到了技術(shù) TL 這個級別坏挠，不能脫離一線太遠(yuǎn)，業(yè)務(wù)細(xì)節(jié)可以不清楚掠拳，大的方向必須要明確癞揉。如果沒有很細(xì)膩的感知能力，很多的決策會有偏差溺欧。

如果他不是一個業(yè)務(wù)架構(gòu)師喊熟，不是一個能給團隊指明更好方向的人，他最終會淪為一個需求翻譯器姐刁，產(chǎn)品經(jīng)理說怎么做就怎么做芥牌。

他更多的只是負(fù)責(zé)保證產(chǎn)品的質(zhì)量、開發(fā)的速度聂使，最終被肢解成一個很瑣碎的人壁拉。

一旦團隊上了一定的規(guī)模，團隊就會從單純的需求實現(xiàn)走向團隊運營柏靶，而運營是需要方向的弃理，業(yè)務(wù)架構(gòu)就是一個基于運營和數(shù)據(jù)的一種綜合的能力。

關(guān)于技術(shù)層面屎蜓，技術(shù) TL 需要具備如下素養(yǎng)：

①技術(shù)視野良好痘昌，解決問題能力與架構(gòu)設(shè)計能力出色

技術(shù) TL 要有良好的技術(shù)視野，不需要各種技術(shù)都樣樣精通炬转，但是必須要有所涉獵辆苔，有所了解，對各種技術(shù)領(lǐng)域的發(fā)展趨勢扼劈，主流非主流技術(shù)的應(yīng)用場景要非常了解驻啤。

知道在什么場景應(yīng)用什么技術(shù)，業(yè)務(wù)發(fā)展到什么規(guī)模應(yīng)該預(yù)先做哪些技術(shù)儲備荐吵。

產(chǎn)品架構(gòu)的設(shè)計要有足夠的彈性骑冗，既能夠保證當(dāng)前開發(fā)的高效率赊瞬，又能夠?qū)ξ磥懋a(chǎn)品架構(gòu)的演進留出擴展的余地。

②動手能力要強沐旨，學(xué)習(xí)能力出色

技術(shù) TL 并不需要自己親自動手寫代碼森逮，但是如有必要，自己可以隨時動手參與第一線的編碼工作磁携，技術(shù) TL 不能長期遠(yuǎn)離一線工作，自廢武功良风，紙上談兵谊迄。否則長此以往，會對技術(shù)的判斷產(chǎn)生嚴(yán)重的失誤烟央。

另外统诺，技術(shù) TL 也應(yīng)該是一個學(xué)習(xí)能力非常出色的人，畢竟 IT 行業(yè)的技術(shù)更新?lián)Q代速度非骋杉螅快粮呢，如果沒有快速學(xué)習(xí)能力，是沒有資格做好技術(shù) TL 的钞艇。

技術(shù) TL 除了管人和管事之外啄寡，其他還有很多事情要做，包括建立團隊研發(fā)文化哩照、團隊人才培養(yǎng)與建設(shè)挺物、跨部門協(xié)調(diào)與溝通等。

這樣也要求技術(shù) TL 同時需要具備良好的溝通和管理能力飘弧，以上觀點僅是個人的一些思考和觀點识藤，僅供參考，不喜勿噴次伶。