摘要：的報(bào)告進(jìn)一步證實(shí)了與成功項(xiàng)目最密切的因素是良好的需求管理，也就是項(xiàng)目的范圍管理，特別是管理好項(xiàng)目的變更。需求管理的第一步就是要梳理不同來(lái)源的需求，主要包括從產(chǎn)品定位出發(fā)外部用戶反饋競(jìng)爭(zhēng)對(duì)手情況市場(chǎng)變化以及內(nèi)部運(yùn)營(yíng)人員客服人員開發(fā)人員的反饋。

阿里妹導(dǎo)讀：技術(shù)主管，又叫「技術(shù)經(jīng)理」，英文一般是 Tech Leader ，簡(jiǎn)稱 TL。隨著工作經(jīng)驗(yàn)的不斷積累，能力的不斷提升，每個(gè)人都有機(jī)會(huì)成為Team Leader。然而在機(jī)會(huì)到來(lái)前，我們必須提前做好準(zhǔn)備，對(duì)TL的工作職責(zé)有一定了解。當(dāng)然，這也會(huì)為當(dāng)下更好地配合TL工作打下基礎(chǔ)。

今天，阿里巴巴高級(jí)技術(shù)專家云狄將結(jié)合自己多年的經(jīng)驗(yàn)，從開發(fā)規(guī)范、開發(fā)流程、技術(shù)規(guī)劃與管理三個(gè)角度出發(fā)，分享對(duì)技術(shù)TL這一角色的理解與思考，歡迎一起探討交流。

「技術(shù)主管」是開發(fā)團(tuán)隊(duì)中的某位程序員需要對(duì)一起創(chuàng)建系統(tǒng)的整個(gè)開發(fā)團(tuán)隊(duì)負(fù)責(zé)時(shí)所承擔(dān)的角色。通常他既要對(duì)最終交付的軟件系統(tǒng)負(fù)責(zé)，另外也會(huì)像一個(gè)程序員一樣去開發(fā)實(shí)現(xiàn)系統(tǒng)。

一個(gè)技術(shù)主管的 60% ～ 70% 的時(shí)間可能花在了開發(fā)任務(wù)分解分配、開發(fā)實(shí)踐、技術(shù)架構(gòu)評(píng)審、代碼審核和風(fēng)險(xiǎn)識(shí)別上，而余下的 30% ～ 40% 的時(shí)間則花在為了保障系統(tǒng)按時(shí)交付所需的各種計(jì)劃、協(xié)作、溝通、管理上。和團(tuán)隊(duì)管理者不同的是，技術(shù)主管的大部分管理工作都是針對(duì)具體研發(fā)任務(wù)和技術(shù)事務(wù)的。

接下來(lái)基于我在技術(shù)TL這個(gè)角色上，在開發(fā)規(guī)范、開發(fā)流程、技術(shù)管理與規(guī)劃等方面我的一些心路歷程，和大家共勉。

我當(dāng)時(shí)負(fù)責(zé)的業(yè)務(wù)是集團(tuán)收購(gòu)一家子公司的業(yè)務(wù)，在整體技術(shù)標(biāo)規(guī)范上與集團(tuán)的技術(shù)標(biāo)準(zhǔn)存在很大的差異。開發(fā)規(guī)范可以說(shuō)是我來(lái)到這個(gè)團(tuán)隊(duì)干的第一件事，我當(dāng)時(shí)面對(duì)的問(wèn)題是API接口格式混亂，沒(méi)有標(biāo)準(zhǔn)的RPC服務(wù)化，代碼沒(méi)有統(tǒng)一標(biāo)準(zhǔn)的開發(fā)規(guī)范，技術(shù)框架組件非標(biāo)準(zhǔn)化等一系列問(wèn)題，作為一名業(yè)務(wù)上的新人，我第一時(shí)間制定了一套相對(duì)標(biāo)準(zhǔn)、全面的技術(shù)開發(fā)規(guī)范，邊寫代碼邊梳理開發(fā)規(guī)范，引領(lǐng)團(tuán)隊(duì)走向統(tǒng)一標(biāo)準(zhǔn)化開發(fā)道路。

針對(duì)團(tuán)隊(duì)研發(fā)規(guī)范暴露的上述問(wèn)題，主要制定了如下規(guī)范：

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

具體規(guī)范包括包命名、類的命名、接口命名、方法命名、變量命名、常量命名。

約定了IDEA/Eclipse IDE代碼的統(tǒng)一模板，代碼風(fēng)格一定要統(tǒng)一，避免不同開發(fā)人員使用不同模板帶來(lái)的差異化以及代碼merge成本。使用IDEA的同學(xué)可以安裝Eclipse Code Formatter插件，和Eclipse統(tǒng)一代碼模板。

所有二方庫(kù)、三方庫(kù)的版本統(tǒng)一定義到parent pom里，這樣來(lái)所有業(yè)務(wù)應(yīng)用工程統(tǒng)一繼承parent pom里所指定的二方庫(kù)、三方庫(kù)的版本，統(tǒng)一框架與工具的版本(Spring、Apache commons工具類、日志組件、JSON處理、數(shù)據(jù)庫(kù)連接池等)，同時(shí)要求生產(chǎn)環(huán)境禁用SNAPSHOT版本。這樣以來(lái)升級(jí)通用框架與工具的版本，只需要應(yīng)用工程升級(jí)parent pom即可。

基于Angular Commit Message規(guī)范生成統(tǒng)一的ChangeLog，這樣一來(lái)對(duì)于每次發(fā)布release tag非常清晰，Mac下都需要安裝對(duì)應(yīng)的插件，IDEA也有對(duì)應(yīng)的插件，具體可以參考阮一峰老師的《Commit message 和 Change log 編寫指南》。

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

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

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

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

success代表接口處理響應(yīng)結(jié)果成功還是失敗，errorCode、errorMsg表示返回錯(cuò)誤碼和錯(cuò)誤消息，module表示返回結(jié)果集，把ResultDTO定義到common-api頂層二方庫(kù)，這樣以來(lái)各個(gè)應(yīng)用不需要來(lái)回轉(zhuǎn)換返回結(jié)果。

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

異常處理不僅僅是狹義上遇到了Exception怎么去處理，還有各種業(yè)務(wù)邏輯遇到錯(cuò)誤的時(shí)候我們?cè)趺慈ヌ幚?。service服務(wù)層捕獲的異常主要包括BusinessException(業(yè)務(wù)異常)、RetriableException (可重試異常) 到 common-api，定義一個(gè)公共異常攔截器，對(duì)業(yè)務(wù)異常、重試異常進(jìn)行統(tǒng)一處理，對(duì)于可重試的異常調(diào)用的服務(wù)接口需要保證其冪等性。

另外其他業(yè)務(wù)層有些特殊異常不需要攔截器統(tǒng)一處理，內(nèi)部可以進(jìn)行自我消化處理掉，根據(jù)場(chǎng)景對(duì)應(yīng)的處理原則主要包括：

直接返回

拋出異常

重試處理

熔斷處理

降級(jí)處理

這又涉及到了彈力設(shè)計(jì)的話題，我們的系統(tǒng)往往會(huì)對(duì)接各種依賴外部服務(wù)、Api，大部分服務(wù)都不會(huì)有SLA，即使有在大并發(fā)下我們也需要考慮外部服務(wù)不可用對(duì)自己的影響，會(huì)不會(huì)把自己拖死。我們總是希望：

盡可能以小的代價(jià)通過(guò)嘗試讓業(yè)務(wù)可以完成；

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

如果外部服務(wù)特別重要，我們往往會(huì)考慮引入多個(gè)同類型的服務(wù)，根據(jù)價(jià)格、服務(wù)標(biāo)準(zhǔn)做路由，在出現(xiàn)問(wèn)題的時(shí)候自動(dòng)降級(jí)。

推薦使用Netflix開源的hystrix容災(zāi)框架，主要解決當(dāng)外部依賴出現(xiàn)故障時(shí)拖垮業(yè)務(wù)系統(tǒng)、甚至引起雪崩的問(wèn)題。目前我團(tuán)隊(duì)也在使用，能夠很好的解決異常熔斷、超時(shí)熔斷、基于并發(fā)數(shù)限流熔斷的降級(jí)處理。

早期的時(shí)候源碼的版本管理基于 svn，后來(lái)逐步切換到 git，分支如何管理每一個(gè)公司（在Gitflow的基礎(chǔ)上）都會(huì)略有不同。

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

分支的定義（master、develop、release、hotfix、feature）

分支命名規(guī)范

checkout、merge request流程

提測(cè)流程

上線流程

Hotfix流程

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

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

提高開發(fā)和測(cè)試的工作效率，人多也亂；

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

方便運(yùn)維處理發(fā)布和回滾；

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

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

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

WARN和ERROR的選擇需要好好考慮，WARN一般我傾向于記錄可自恢復(fù)但值得關(guān)注的錯(cuò)誤，ERROR代表了不能自己恢復(fù)的錯(cuò)誤。對(duì)于業(yè)務(wù)處理遇到問(wèn)題用ERROR不合理，對(duì)于catch到了異常也不是全用ERROR。

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

記錄了上下問(wèn)信息，是否要考慮日志脫敏問(wèn)題？可以在框架層面實(shí)現(xiàn)，比如自定義實(shí)現(xiàn)logback的ClassicConverter。

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

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

對(duì)開發(fā)過(guò)程中所用到的公共組件進(jìn)行了統(tǒng)一抽象與封裝，包括 dao 層框架mybatis、cache 組件 jetcache、httpclien t組件、common-tools (公共工具)，同時(shí)抽取出全局唯一ID、分布式鎖、冪等等公共組件，把以上公共組件進(jìn)行集成到各個(gè)應(yīng)用，進(jìn)行統(tǒng)一升級(jí)、維護(hù)，這樣以來(lái)方便大家將更多的精力集中到業(yè)務(wù)開發(fā)上。

目前團(tuán)隊(duì)的開發(fā)模式還是基于傳統(tǒng)的瀑布開發(fā)模式，整體開發(fā)流程涉及需求評(píng)審、測(cè)試用例評(píng)審、技術(shù)架構(gòu)評(píng)審、開發(fā)與測(cè)試、驗(yàn)收與上線，這里主要基于TL的角度從需求管理、技術(shù)架構(gòu)評(píng)審、代碼評(píng)審、發(fā)布計(jì)劃評(píng)審幾個(gè)關(guān)鍵重點(diǎn)環(huán)節(jié)進(jìn)行探討，歡迎拍磚。

美國(guó)專門從事跟蹤IT項(xiàng)目成功或失敗的權(quán)威機(jī)構(gòu) Standish Group的CHAOS Reports 報(bào)導(dǎo)了該公司的一項(xiàng)研究，該公司對(duì)多個(gè)項(xiàng)目作調(diào)查后發(fā)現(xiàn)，百分之七十四的項(xiàng)目是失敗的，既這些項(xiàng)目不能按時(shí)按預(yù)算完成。其中提到最多的導(dǎo)致項(xiàng)目失敗的原因就是"變更用戶需求"。另外從歷年的 Standish Group 報(bào)告分析看，導(dǎo)致項(xiàng)目失敗的最重要原因與需求有關(guān)。Standish Group 的CHAOS 報(bào)告進(jìn)一步證實(shí)了與成功項(xiàng)目最密切的因素是良好的需求管理，也就是項(xiàng)目的范圍管理，特別是管理好項(xiàng)目的變更。

產(chǎn)品因需求而生，在產(chǎn)品的整個(gè)生命周期中，產(chǎn)品經(jīng)理會(huì)收到來(lái)自各個(gè)方面的需求，但是每一個(gè)需求的必要性、重要性和實(shí)現(xiàn)成本都需要經(jīng)過(guò)深思熟慮的分析和計(jì)劃，避免盲目的決定需求或者變更需求，這樣很容易導(dǎo)致工作混亂，技術(shù)TL如果不能正確的對(duì)需求進(jìn)行把控，會(huì)導(dǎo)致整個(gè)項(xiàng)目偏離正確的軌道。

需求管理的第一步就是要梳理不同來(lái)源的需求，主要包括從產(chǎn)品定位出發(fā)、外部用戶反饋、競(jìng)爭(zhēng)對(duì)手情況、市場(chǎng)變化以及內(nèi)部運(yùn)營(yíng)人員、客服人員、開發(fā)人員的反饋。首先技術(shù)TL對(duì)產(chǎn)品有足夠認(rèn)知和把控，簡(jiǎn)單來(lái)說(shuō)就是我的產(chǎn)品是為了滿足哪些人的哪些需求而做，產(chǎn)品需求一定要根植于客戶的需求、根植于客戶的環(huán)境。每款產(chǎn)品必定有其核心價(jià)值，能夠?yàn)榭蛻魟?chuàng)造更多的價(jià)值，基于此考慮往往能得到一些核心需求，摒除價(jià)值不大的需求。

需求管理中最重要的就是對(duì)發(fā)散性需求的管理，往往因此也會(huì)導(dǎo)致產(chǎn)品在執(zhí)行過(guò)程中不斷的變更或增加需求。由于人的思維是發(fā)散性的，所以往往在產(chǎn)品構(gòu)思的過(guò)程中會(huì)出現(xiàn)各種新鮮好玩的想法，這些想法可能來(lái)自領(lǐng)導(dǎo)或者產(chǎn)品經(jīng)理自己，但是這些想法往往都是和產(chǎn)品核心方向不相關(guān)的，但是由于這些想法能夠在當(dāng)時(shí)帶來(lái)誘惑，因此這些不相關(guān)的需求會(huì)嚴(yán)重干擾了技術(shù)團(tuán)隊(duì)的精力，打亂或者延誤產(chǎn)品原本的計(jì)劃。同樣技術(shù)研發(fā)同學(xué)也需要建立對(duì)產(chǎn)品的深度思考，不要把自己定位成產(chǎn)品需求的實(shí)現(xiàn)者，同樣需要對(duì)需求負(fù)責(zé)。

很多時(shí)候需求的變更或增加是因?yàn)槲覀兠媾R太多選擇和想要的太多，沒(méi)有適當(dāng)?shù)目刂谱约旱挠?，并以自己的喜好?lái)決定需求，這些因素很容易導(dǎo)致產(chǎn)品沒(méi)有明確的方向、團(tuán)隊(duì)成員疲于奔命，但是卻沒(méi)有實(shí)際的成果。所以技術(shù)TL一定要能夠評(píng)估出重新審視產(chǎn)品和篩選需求的優(yōu)先級(jí)，識(shí)別每一個(gè)需求的必要性、重要性和實(shí)現(xiàn)成本。通過(guò)深思熟慮給團(tuán)隊(duì)明確方向并專注，聚焦資源的支配，確保團(tuán)隊(duì)的精力都聚焦在產(chǎn)品的核心需求上。

互聯(lián)網(wǎng)時(shí)代，大家提倡敏捷迭代，總嫌傳統(tǒng)方式太重，流程復(fù)雜，影響效率，什么都希望短平快，在扁平化的組織中，經(jīng)常是需求火速分發(fā)到一線研發(fā)，然后就靠個(gè)人折騰去了，其實(shí)技術(shù)架構(gòu)評(píng)審這同樣是一個(gè)非常重要的環(huán)節(jié)。架構(gòu)評(píng)審或技術(shù)方案評(píng)審的價(jià)值在于集眾人的力量大家一起來(lái)分析看看方案里是否有坑，方案上線后是否會(huì)遇到不可逾越的重大技術(shù)問(wèn)題，提前盡可能把一些事情先考慮到提出質(zhì)疑其實(shí)對(duì)項(xiàng)目的健康發(fā)展有很大的好處。

基于架構(gòu)評(píng)審，我們的目標(biāo)核心是要滿足以下幾點(diǎn)：

1.設(shè)計(jì)把關(guān)，確保方案合格，各方面都考慮到了，避免缺陷和遺漏，不求方案多牛，至少不犯錯(cuò)。

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

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

通過(guò)評(píng)審發(fā)掘創(chuàng)新亮點(diǎn)，推廣最佳實(shí)踐。

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

技術(shù)選型：為什么選用A組件不選用B、C組件，A是開源的，開源協(xié)議是啥？基于什么語(yǔ)言開發(fā)的，出了問(wèn)題我們自身是否能夠維護(hù)？性能方面有沒(méi)有壓測(cè)過(guò)？這些所有問(wèn)題作為技術(shù)選型我們都需要考慮清楚，才能做最終決定。

高性能：產(chǎn)品對(duì)應(yīng)的TPS、QPS和RT是多少？設(shè)計(jì)上會(huì)做到的TPS、QPS和RT是多少？而實(shí)際上我們整體隨著數(shù)據(jù)量的增大系統(tǒng)性能會(huì)不會(huì)出現(xiàn)明顯問(wèn)題？隨著業(yè)務(wù)量、數(shù)據(jù)量的上升，我們的系統(tǒng)的性能如何去進(jìn)一步提高？系統(tǒng)哪個(gè)環(huán)節(jié)會(huì)是最大的瓶頸？是否有抗突發(fā)性能壓力的能力，大概可以滿足多少的TPS和QPS，怎么去做來(lái)實(shí)現(xiàn)高性能，這些問(wèn)題都需要我們?nèi)ニ伎肌?/p>

高可用：是否有單點(diǎn)的組件，非單點(diǎn)的組件如何做故障轉(zhuǎn)移？是否考慮過(guò)多活的方案？是否有數(shù)據(jù)丟失的可能性？數(shù)據(jù)丟失如何恢復(fù)？出現(xiàn)系統(tǒng)宕機(jī)情況，對(duì)業(yè)務(wù)會(huì)造成哪些影響？有無(wú)其他補(bǔ)救方案？這些問(wèn)題需要想清楚，有相應(yīng)的解決方案。

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

可伸縮性：每個(gè)環(huán)節(jié)的服務(wù)是不是無(wú)狀態(tài)的？是否都是可以快速橫向擴(kuò)展的？擴(kuò)容需要怎么做手動(dòng)還是自動(dòng)？擴(kuò)展后是否可以提高響應(yīng)速度？這所有的問(wèn)題都需要我們?nèi)ニ伎记宄⒂袑?duì)應(yīng)的解決方案。

彈性處理：消息重復(fù)消費(fèi)、接口重復(fù)調(diào)用對(duì)應(yīng)的服務(wù)是否保證冪等？是否考慮了服務(wù)降級(jí)？哪些業(yè)務(wù)支持降級(jí)？支持自動(dòng)降級(jí)還是手工降級(jí)？是否考慮了服務(wù)的超時(shí)熔斷、異常熔斷、限流熔斷？觸發(fā)熔斷后對(duì)客戶的影響？服務(wù)是否做了隔離，單一服務(wù)故障是否影響全局？這些問(wèn)題統(tǒng)統(tǒng)需要我們想清楚對(duì)應(yīng)的解決方案，才會(huì)進(jìn)一步保證架構(gòu)設(shè)計(jì)的合理性。

兼容性：上下游依賴是否梳理過(guò)，影響范圍多大？怎么進(jìn)行新老系統(tǒng)替換？新老系統(tǒng)能否來(lái)回切換？數(shù)據(jù)存儲(chǔ)是否兼容老的數(shù)據(jù)處理？如果對(duì)你的上下游系統(tǒng)有影響，是否通知到上下游業(yè)務(wù)方？上下游依賴方進(jìn)行升級(jí)的方案成本如何最小化？這些問(wèn)題需要有完美的解決方案，稍有不慎會(huì)導(dǎo)致故障。

安全性：是否徹底避免SQL注入和XSS？是否有數(shù)據(jù)泄露的可能性？是否做了風(fēng)控策略？接口服務(wù)是否有防刷保護(hù)機(jī)制？數(shù)據(jù)、功能權(quán)限是否做了控制？小二后臺(tái)系統(tǒng)是否做了日志審計(jì)？數(shù)據(jù)傳輸是否加密驗(yàn)簽？應(yīng)用代碼中是否有明文的AK/SK、密碼？這些安全細(xì)節(jié)問(wèn)題需要我們統(tǒng)統(tǒng)考慮清楚，安全問(wèn)題任何時(shí)候都不能輕視。

可測(cè)性：測(cè)試環(huán)境和線上的差異多大？是否可以在線上做壓測(cè)？線上壓測(cè)怎么隔離測(cè)試數(shù)據(jù)？是否有測(cè)試白名單功能？是否支持部署多套隔離的測(cè)試環(huán)境？測(cè)試黑盒白盒工作量的比例是怎么樣的？新的方案是否非常方便測(cè)試，在一定程度也需要考量。

可運(yùn)維性：系統(tǒng)是否有初始化或預(yù)熱的環(huán)節(jié)？數(shù)據(jù)是否指數(shù)級(jí)別遞增？業(yè)務(wù)數(shù)據(jù)是否需要定期歸檔處理？隨著時(shí)間的推移如果壓力保持不變的話系統(tǒng)需要怎么來(lái)巡檢和維護(hù)？業(yè)務(wù)運(yùn)維方面的設(shè)計(jì)也需要充分考慮到。

監(jiān)控與報(bào)警：對(duì)外部依賴的接口是否添加了監(jiān)控與報(bào)警？應(yīng)用層面系統(tǒng)內(nèi)部是否有暴露了一些指標(biāo)作監(jiān)控和報(bào)警？系統(tǒng)層面使用的中間件和存儲(chǔ)是否有監(jiān)控報(bào)警？只有充分考慮到各個(gè)環(huán)節(jié)的監(jiān)控、報(bào)警，任何問(wèn)題會(huì)第一時(shí)間通知到研發(fā)，阻止故障進(jìn)一步擴(kuò)散。

其實(shí)不同階段的項(xiàng)目有不同的目標(biāo)，我們不會(huì)在項(xiàng)目起步的時(shí)候做99.99%的可用性支持百萬(wàn)QPS的架構(gòu)，高效完成項(xiàng)目的業(yè)務(wù)目標(biāo)也是架構(gòu)考慮的因素之一。而且隨著項(xiàng)目的發(fā)展，隨著公司中間件和容器的標(biāo)準(zhǔn)化，很多架構(gòu)的工作被標(biāo)準(zhǔn)化替代，業(yè)務(wù)代碼需要考慮架構(gòu)方面伸縮性運(yùn)維性等等的需求越來(lái)越少，慢慢的這些工作都能由架構(gòu)和運(yùn)維團(tuán)隊(duì)來(lái)接。一開始的時(shí)候我們可以花一點(diǎn)時(shí)間來(lái)考慮這些問(wèn)題，但是不是所有的問(wèn)題都需要有最終的方案。

代碼質(zhì)量包括功能性代碼質(zhì)量和非功能性代碼質(zhì)量，功能質(zhì)量大多通過(guò)測(cè)試能夠去發(fā)現(xiàn)問(wèn)題，非功能性代碼質(zhì)量用戶不能直接體驗(yàn)到這種質(zhì)量的好壞，代碼質(zhì)量不好，最直接的“受害者”是開發(fā)者或組織自身，因?yàn)榇a質(zhì)量好壞直接決定了軟件的可維護(hù)性成本的高低。代碼質(zhì)量應(yīng)該更多的應(yīng)該從可測(cè)性，可讀性，可理解性，容變性等代碼可維護(hù)性維度去衡量，其中 CodeReview 是保證代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié)，建立良好的 CodeReview 規(guī)范與習(xí)慣，對(duì)于一個(gè)技術(shù)團(tuán)隊(duì)是一件非常重要核心的事情，沒(méi)有 CodeReview 的團(tuán)隊(duì)沒(méi)有未來(lái)。

每次項(xiàng)目開發(fā)自測(cè)完成后，通常會(huì)組織該小組開發(fā)人員集體進(jìn)行代碼 review，代碼 review 一般 review 代碼質(zhì)量以及規(guī)范方面的問(wèn)題，另外需要關(guān)注的是每一行代碼變更是否與本次需求相關(guān)，如果存在搭車發(fā)布或者代碼重構(gòu)優(yōu)化，需要自行保證測(cè)試通過(guò)，否則不予發(fā)布。

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

確認(rèn)代碼功能：代碼實(shí)現(xiàn)的功能滿足產(chǎn)品需求，邏輯的嚴(yán)謹(jǐn)和合理性是最基本的要求。同時(shí)需要考慮適當(dāng)?shù)臄U(kuò)展性，在代碼的可擴(kuò)展性和過(guò)度設(shè)計(jì)做出權(quán)衡，不編寫無(wú)用邏輯和一些與代碼功能無(wú)關(guān)的附加代碼。

在真正需要某些功能的時(shí)候才去實(shí)現(xiàn)它，而不是你預(yù)見(jiàn)到它將會(huì)有用。 —— RonJeffries

編碼規(guī)范：以集團(tuán)開發(fā)規(guī)約、靜態(tài)代碼規(guī)約為前提，是否遵守了編碼規(guī)范，遵循了最佳實(shí)踐。除了形式上的要求外，更重要的是命名規(guī)范。目標(biāo)是提高代碼的可讀性，降低代碼可維護(hù)性成本。

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

文檔和注釋：過(guò)少（缺少必要信息）、過(guò)多（沒(méi)有信息量）、過(guò)時(shí)的文檔或注釋，總之文檔和注釋要與時(shí)俱進(jìn)，與最新代碼保持同步。其實(shí)很多時(shí)候個(gè)人覺(jué)得良好的變量、函數(shù)命名是最好的注釋，好的代碼勝過(guò)注釋。

重復(fù)代碼：當(dāng)一個(gè)項(xiàng)目在不斷開發(fā)迭代、功能累加的過(guò)程中，重復(fù)代碼的出現(xiàn)幾乎是不可避免的，通?？梢酝ㄟ^(guò)PMD工具進(jìn)行檢測(cè)。類型體系之外的重復(fù)代碼處理通?？梢苑庋b到對(duì)應(yīng)的Util類或者Helper類中，類體系之內(nèi)的重復(fù)代碼通?？梢酝ㄟ^(guò)繼承、模板模式等方法來(lái)解決。

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

監(jiān)控與報(bào)警：基于產(chǎn)品的需求邏輯，需要有些指標(biāo)來(lái)證明業(yè)務(wù)是正常work的，如果發(fā)生異常需要有監(jiān)控、報(bào)警指標(biāo)通知研發(fā)人員處理，review業(yè)務(wù)需求對(duì)應(yīng)的監(jiān)控與報(bào)警指標(biāo)也是Code Review的重點(diǎn)事項(xiàng)。

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

實(shí)際上維護(hù)單元測(cè)試的成本不比開發(fā)成本低，這點(diǎn)團(tuán)隊(duì)目前做的的不到位。

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

涉及到10人日以上的項(xiàng)目，必須有明確的發(fā)布計(jì)劃，并組織項(xiàng)目成員統(tǒng)一參加項(xiàng)目發(fā)布計(jì)劃review，發(fā)布計(jì)劃主要包含如下幾點(diǎn)：

1）明確是否有外部依賴接口，如有請(qǐng)同步協(xié)調(diào)好業(yè)務(wù)方；

2）發(fā)布前配置確認(rèn)包括配置文件、數(shù)據(jù)庫(kù)配置、中間件配置等各種配置，尤其各種環(huán)境下的差異化配置項(xiàng)；

3）二方庫(kù)發(fā)布順序，是否有依賴；

4）應(yīng)用發(fā)布順序；

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

6）回滾計(jì)劃，必須要有回滾計(jì)劃，發(fā)布出現(xiàn)問(wèn)題要有緊急回滾策略；

7）生產(chǎn)環(huán)境回歸測(cè)試重點(diǎn)Case。

我在帶技術(shù)團(tuán)隊(duì)的這些年，對(duì)團(tuán)隊(duì)一直有一個(gè)要求，每周都要做系統(tǒng)健康度巡檢，未雨綢繆、晴天修屋頂，避免在極端場(chǎng)景下某些隱藏的bug轉(zhuǎn)變成了故障。

為什么要把系統(tǒng)健康度巡檢放到技術(shù)管理里，我覺(jué)得這是一個(gè)非常重要的環(huán)節(jié)。像傳統(tǒng)的航空、電力、汽車行業(yè)都要有一定的巡檢機(jī)制，保障設(shè)備系統(tǒng)正常運(yùn)轉(zhuǎn)，同樣軟件系統(tǒng)也同樣需要巡檢機(jī)制保障業(yè)務(wù)健康發(fā)展。

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

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

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

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

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

慢查詢：MYSQL慢查詢需要重點(diǎn)關(guān)注，隨著數(shù)據(jù)量上漲，需要對(duì)慢查詢進(jìn)行優(yōu)化。

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

技術(shù)規(guī)劃通常由團(tuán)隊(duì)的TL負(fù)責(zé)，每個(gè)財(cái)年TL需要從大局的角度去思考每個(gè)季度的技術(shù)優(yōu)化規(guī)劃，去償還技術(shù)債，技術(shù)債也是有利息的，因?yàn)槔⒌拇嬖?，技術(shù)債務(wù)不及時(shí)償還的話，會(huì)在未來(lái)呈現(xiàn)出非線性增長(zhǎng)，造成始料不及的損失。

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

架構(gòu)優(yōu)化：一些結(jié)構(gòu)不良、低內(nèi)聚高耦合的代碼則會(huì)使得哪怕是微小的需求變更或功能擴(kuò)展都無(wú)從下手，修改的代價(jià)很可能超過(guò)了重寫的代價(jià)。同樣系統(tǒng)之間的耦合也需要重點(diǎn)去關(guān)注，遵循微服務(wù)化的原則，系統(tǒng)也要遵循單一職責(zé)原則，對(duì)于職責(zé)不清晰的系統(tǒng)去做解耦優(yōu)化，進(jìn)行一些模塊化改造、服務(wù)隔離、公用服務(wù)抽象。

性能優(yōu)化：基于財(cái)年對(duì)于業(yè)務(wù)量、數(shù)據(jù)量的發(fā)展評(píng)估，根據(jù)目前系統(tǒng)服務(wù)的QPSRT,需要提前規(guī)劃對(duì)系統(tǒng)性能進(jìn)行一些升級(jí)策略，包括重點(diǎn)關(guān)注對(duì)一些慢接口、慢查詢的優(yōu)化。

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

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

大家不知道有沒(méi)有類似的經(jīng)歷，某個(gè)時(shí)間段突然一些線上故障頻發(fā)，各種技術(shù)債、業(yè)務(wù)債被業(yè)務(wù)方窮追猛打要求還債，如果出現(xiàn)這種現(xiàn)象很大程度這個(gè)TL已經(jīng)失位了，這個(gè)團(tuán)隊(duì)失控了。也曾經(jīng)有人跟我吐槽他的TL把活都分給他們，而TL自己什么都不干！這個(gè)技術(shù)TL真的什么都不干？曾經(jīng)有一段時(shí)間我也在思考技術(shù)TL的核心職責(zé)到底是什么？技術(shù)TL應(yīng)該具備哪些素質(zhì)？

首先技術(shù)說(shuō)到底是為業(yè)務(wù)服務(wù)的，除非技術(shù)就是業(yè)務(wù)本身，必須體現(xiàn)它的商業(yè)價(jià)值。在很多公司里技術(shù)研發(fā)真的就成了實(shí)現(xiàn)其他部門需求的工具，我覺(jué)得這樣的技術(shù)TL肯定是不合格的。首先它不能影響業(yè)務(wù)發(fā)展，需求提出方會(huì)經(jīng)過(guò)很多轉(zhuǎn)化，如果不是不假思索傳遞需求，整個(gè)過(guò)程會(huì)失真。

第二個(gè)，我認(rèn)為最最重要的是架構(gòu)設(shè)計(jì)的能力，可能管理能力還次之。對(duì)于管理能力我認(rèn)為最重要的是對(duì)團(tuán)隊(duì)的感知能力，因?yàn)橐坏┑搅思夹g(shù)TL這個(gè)級(jí)別，不能脫離一線太遠(yuǎn)，業(yè)務(wù)細(xì)節(jié)可以不清楚，大的方向必須要明確。如果沒(méi)有很細(xì)膩的感知能力，很多的決策會(huì)有偏差。

如果他不是一個(gè)業(yè)務(wù)架構(gòu)師，不是一個(gè)能給團(tuán)隊(duì)指明更好方向的人，他最終會(huì)淪為一個(gè)需求翻譯器，產(chǎn)品經(jīng)理說(shuō)怎么做就怎么做。他更多的只是負(fù)責(zé)保證產(chǎn)品的質(zhì)量、開發(fā)的速度，最終被肢解成一個(gè)很瑣碎的人。一旦團(tuán)隊(duì)上了一定的規(guī)模，團(tuán)隊(duì)就會(huì)從單純的需求實(shí)現(xiàn)走向團(tuán)隊(duì)運(yùn)營(yíng)，而運(yùn)營(yíng)是需要方向的，業(yè)務(wù)架構(gòu)就是一個(gè)基于運(yùn)營(yíng)和數(shù)據(jù)的一種綜合的能力。

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

技術(shù)視野良好，解決問(wèn)題能力與架構(gòu)設(shè)計(jì)能力出色。

技術(shù)TL要有良好的技術(shù)視野，不需要各種技術(shù)都樣樣精通，但是必須要所有涉獵，有所了解，對(duì)各種技術(shù)領(lǐng)域的發(fā)展趨勢(shì)，主流非主流技術(shù)的應(yīng)用場(chǎng)景要非常了解。知道在什么場(chǎng)景應(yīng)用什么技術(shù)，業(yè)務(wù)發(fā)展到什么規(guī)模應(yīng)該預(yù)先做哪些技術(shù)儲(chǔ)備。產(chǎn)品架構(gòu)的設(shè)計(jì)要有足夠的彈性，既能夠保證當(dāng)前開發(fā)的高效率，又能夠?qū)ξ磥?lái)產(chǎn)品架構(gòu)的演進(jìn)留出擴(kuò)展的余地。

動(dòng)手能力要強(qiáng)，學(xué)習(xí)能力出色。

技術(shù)TL并不需要自己親自動(dòng)手寫代碼，但是如有必要，自己可以隨時(shí)動(dòng)手參與第一線的編碼工作，技術(shù)TL不能長(zhǎng)期遠(yuǎn)離一線工作，自廢武功，紙上談兵。否則長(zhǎng)此以往，會(huì)對(duì)技術(shù)的判斷產(chǎn)生嚴(yán)重的失誤。另外，技術(shù)TL也應(yīng)該是一個(gè)學(xué)習(xí)能力非常出色的人，畢竟IT行業(yè)的技術(shù)更新?lián)Q代速度非?？?，如果沒(méi)有快速學(xué)習(xí)能力，是沒(méi)有資格做好技術(shù)TL的。

技術(shù)TL除了管人和管事之外，其他還有很多事情要做包括建立團(tuán)隊(duì)研發(fā)文化、團(tuán)隊(duì)人才培養(yǎng)與建設(shè)、跨部門協(xié)調(diào)與溝通等，這樣以要求技術(shù)TL也同時(shí)也需要具備良好的溝通和管理能力，以上觀點(diǎn)僅是個(gè)人的一些思考和觀點(diǎn)，僅供參考。

閱讀原文

本文來(lái)自云棲社區(qū)合作伙伴“?阿里技術(shù)”，如需轉(zhuǎn)載請(qǐng)聯(lián)系原作者。