我工作的前 5 年，都是從事基礎(chǔ)系統(tǒng)研發(fā)相關(guān)的工作，做過后臺(tái)的接入層、后臺(tái)的存儲(chǔ)系統(tǒng)、RPC 框架。

[[261946]] 

說來不怕你笑話，那個(gè)時(shí)期，我對(duì)代碼一直有一種恐懼感。這種恐懼是怎么來的呢?且讓我慢慢說來。

我們所構(gòu)建的基礎(chǔ)系統(tǒng)，都是使用在億級(jí)甚至十億級(jí)用戶產(chǎn)品的業(yè)務(wù)系統(tǒng)之上的。

從客戶端(前端)到后臺(tái)業(yè)務(wù)邏輯層，再到基礎(chǔ)架構(gòu)層，所寫的代碼是跑在整個(gè)調(diào)用鏈路的后端。你可以認(rèn)為，幾乎每個(gè)用戶的每個(gè)請(qǐng)求都會(huì)跑到我們寫的那部分代碼。

這個(gè)對(duì)系統(tǒng)帶來的影響是：

• 代碼出問題后，影響的用戶范圍會(huì)很大。
• 在這億級(jí)甚至十億級(jí)用戶量的情況下，每天所帶來的請(qǐng)求可能是千億級(jí)，萬億級(jí)的。

在如此龐大請(qǐng)求量的情況下，幾乎各種奇葩的異常，你都會(huì)遇到，代碼要極其的健壯，一個(gè)小異常沒處理好就會(huì)帶來大麻煩。

這讓我想起來，我們故障時(shí)候的情形。幾年前，我們每做完一次版本變更，晚上基本都會(huì)睡不好，擔(dān)心變更的代碼有問題。

對(duì)手機(jī)的報(bào)警短信特別敏感，一有風(fēng)吹草動(dòng)，立馬就會(huì)打開電腦 VPN 看看，即使是在深夜凌晨的時(shí)候。

我自己有個(gè)習(xí)慣，每次變更完，都要間隔幾個(gè)小時(shí)去看看監(jiān)控曲線和日志，看看有沒有異常的苗頭，一旦發(fā)現(xiàn)有不對(duì)勁地方，就會(huì)立即著手排查，直到確保沒有問題為止。

[[261947]] 

不過即使如此，還是不可避免的會(huì)出現(xiàn)問題。半夜兩三點(diǎn)的時(shí)候，你的手機(jī)突然響起，報(bào)警語音機(jī)器人跟你說，你有一個(gè)重要的監(jiān)控曲線出現(xiàn)異常，請(qǐng)查看。

然后你的血壓立馬升高，心跳加速，你從床上，一躍而起，打開電腦，連上公司的 VPN，立馬著手排查起來。

幾分鐘后，QA(質(zhì)量工程師)電話過來，告知你，這個(gè)故障目前已經(jīng)上報(bào)到部門故障系統(tǒng)，目前影響的用戶有 XXX 的數(shù)量，請(qǐng)你加快處理的速度，然后你的心跳再次加速。

半小時(shí)后，終于有了眉目，這時(shí)，你的 Leader 電話過來，詢問你是怎么回事，大概還需要多長的時(shí)間才能處理完畢。待你語焉不詳?shù)鼗貜?fù)完你的 Leader，你又開始埋頭，一行行的排查故障。

一個(gè)小時(shí)后，你終于將問題定位出來，執(zhí)行了故障處理方案，例如回滾新的代碼，或者屏蔽某些機(jī)器等。你才終于有了喘息的時(shí)間。

(PS：這里正確的流程是，出問題后，立馬回滾代碼，但存儲(chǔ)系統(tǒng)因?yàn)閿?shù)據(jù)的關(guān)系，在沒有確定原因前不太敢回滾，怕對(duì)數(shù)據(jù)有影響。)

你趕緊爬上床去，睡上 2-3 個(gè)小時(shí)，因?yàn)榈诙爝€要早起，趕到公司，去處理故障的后遺癥，數(shù)據(jù)損壞和數(shù)據(jù)錯(cuò)亂。

那個(gè)時(shí)期，我們寫代碼都是特別小心的，變更，更是極度的謹(jǐn)慎。所以使得自己對(duì)代碼變更有了一種焦慮和恐懼的心理。至少在那時(shí)候，寫代碼不是一件輕松的事情。

這個(gè)事情，我現(xiàn)在回過頭來看。你可以認(rèn)為有一部分是人的原因，但仔細(xì)的想想，寫代碼不出 Bug ，幾乎也是極難做到，所以這里在研發(fā)流程上，其實(shí)也是有缺失的。

前期因?yàn)闃I(yè)務(wù)發(fā)展太快，團(tuán)隊(duì)的整體人力跟不上，所以，一開始很多流程，都是很原始的，那時(shí)候，是想做但客觀條件不允許。

后來，業(yè)務(wù)穩(wěn)定了，流程就規(guī)范了不少。比如引入了 Coverity 的代碼檢查，也推行過測(cè)試用例覆蓋，持續(xù)集成等。

但最終，并不是所有的流程都延續(xù)了下去。比如，代碼測(cè)試用例覆蓋，有的團(tuán)隊(duì)到后面就放棄了，需求變化太快，測(cè)試用例成本太高。

Coverity 倒是自動(dòng)化程度高，沒啥人力投入，執(zhí)行了下來。但我相信不是所有的公司，所有的團(tuán)隊(duì)，都會(huì)有這種規(guī)范的流程。一個(gè)是研發(fā)流程成熟度建設(shè)的問題，但除此，還有成本，業(yè)務(wù)迭代速度。

在互聯(lián)網(wǎng)，產(chǎn)品高速迭代的時(shí)候，產(chǎn)品都還沒有存活下來，成熟流程就更不太可能有了。

綜合來看，一種規(guī)范，但相對(duì)較重的研發(fā)流程的建立，應(yīng)該也是根據(jù)具體情況而定的。

需要考慮產(chǎn)品的形態(tài)，產(chǎn)品迭代的速度，團(tuán)隊(duì)的人力預(yù)算成本，產(chǎn)品的生命周期等等。

當(dāng)然，無論怎么說，反正這不是個(gè)人可以決定的事情，如果你所在的團(tuán)隊(duì)有完善的研發(fā)流程，那是好的事情，但如果沒有那么完善，自己又能夠做些什么呢?

我的經(jīng)驗(yàn)來看，以下的一些措施，對(duì)于個(gè)人而言也有不錯(cuò)的效果。

[[261948]] 

測(cè)試驅(qū)動(dòng)的開發(fā)(TDD)

有段時(shí)間，因?yàn)闃I(yè)務(wù)高速發(fā)展，對(duì)性能的要求不斷提高，存儲(chǔ)模型也跟隨著不斷迭代改進(jìn)，所以那段時(shí)間的代碼修改是比較多的，那個(gè)時(shí)間的焦慮感也特別重。

我記得是在 《重構(gòu)：改善既有代碼的設(shè)計(jì)》中了解到 TDD 的。簡單來說， 就是先構(gòu)建測(cè)試用例，再開始寫你的功能代碼。

在設(shè)計(jì)測(cè)試用例之前，你需要先定義好模塊對(duì)外的接口，包括接口的種類，參數(shù)，返回值等。

然后，你針對(duì)定義好的接口，編寫測(cè)試用例。這過程中，你可能會(huì)發(fā)現(xiàn)接口設(shè)計(jì)不合理的地方，也需要隨著修改。

待你測(cè)試用例寫完，基本你的接口也被修改的比較好了，所以 TDD 還能改善你的接口設(shè)計(jì)。

后續(xù)再為每個(gè)接口實(shí)現(xiàn)特定的代碼邏輯。我當(dāng)時(shí)將這種方法運(yùn)用到了一個(gè)磁盤存儲(chǔ)引擎中，發(fā)現(xiàn)相當(dāng)不錯(cuò)。我特地花了一周左右的時(shí)間寫測(cè)試用例。

后面，每天實(shí)現(xiàn)部分的功能后，都立馬跑測(cè)試用例，每次跑完通過，你的心里都有穩(wěn)的一 B 的感覺。有種媽媽再也不擔(dān)心我寫的代碼有 Bug，被老板叼，導(dǎo)致扣工資了。

因?yàn)橛辛送晟频臏y(cè)試用例，而且隨著你測(cè)試用例不斷的增加和覆蓋，你的信心會(huì)越來越足，焦慮自然減少了很多。

不過這種方式，比較適合底層的系統(tǒng)和核心穩(wěn)定的系統(tǒng)。對(duì)于需求多變的系統(tǒng)，構(gòu)建測(cè)試用例的人力付出太大，而且需求一變，已有的測(cè)試用例可能失效，導(dǎo)致投入產(chǎn)出比不夠高。

灰度發(fā)布

簡單來說，就是一個(gè)特性要上線的時(shí)候，不是一下就開放給所有的用戶使用。有點(diǎn)像產(chǎn)品上的內(nèi)測(cè)，只不過是用在技術(shù)上。

比如我新增加了一個(gè)產(chǎn)品需求，例如就微信里面的 “看一看”入口，不是一開始就對(duì)所有用戶開放的。

首先會(huì)上線一個(gè)新的客戶端版本，代碼邏輯已經(jīng)預(yù)埋，但設(shè)計(jì)了一個(gè)開關(guān)，對(duì)所有用戶都是關(guān)閉的。

前期，可能會(huì)找個(gè)千分之一，甚至萬分之一的用戶(隨機(jī)或者特定的用戶群體)，讓他們使用。

在這過程中，收集各種 Log，監(jiān)控，用戶的反饋，來確認(rèn)和 Fix 系統(tǒng)存在的各種問題。

一般經(jīng)過兩三周后，如果沒有大問題，就會(huì)進(jìn)一步的放開使用的用戶。比如變成百分之一，十分之一，一直迭代，直至覆蓋全部用戶。

灰度這個(gè)思想，在互聯(lián)網(wǎng)是特別常用的。客戶端，前端，后臺(tái)都可以使用。比如后臺(tái)，上線一個(gè)新修改后，也不是一下就開放給所有用戶。

而是按照某種規(guī)則，例如以 QQ 用戶為例，可能是這種規(guī)則：計(jì)算 Hash 值(QQ 號(hào)) % 1000 <= 灰度用戶的比例(取 0 --- 1000)。

放量的最小力度就是千分之一，被灰度到的用戶，看到新功能，沒灰度到的用戶不受影響。

這招用在新功能，用在系統(tǒng)優(yōu)化，代碼重構(gòu)上都很不錯(cuò)。付出的額外成本不大，有的公司有自研的灰度系統(tǒng)。

沒有的話，在重大且沒有把握的功能上，自己加上幾行灰度控制代碼也不難。

監(jiān)控和 Log

監(jiān)控和 Log 不是什么新鮮的東西。工作第一年，我們的技術(shù)總監(jiān)在一次會(huì)議上跟我們說：你寫完的代碼是死的，只有在線上跑的代碼是活的。

監(jiān)控和 Log(特別是監(jiān)控)，就像是你代碼的體征信息，隨時(shí)反應(yīng)著你代碼在實(shí)際環(huán)境中的運(yùn)行情況，要高度的重視。

這段話，在后面，我深有感觸。通過完善設(shè)計(jì)的監(jiān)控和 Log，預(yù)先發(fā)現(xiàn)了很多的問題，也避免了很多，或代碼 Bug，或系統(tǒng)設(shè)計(jì)缺陷導(dǎo)致重大故障。

后面，監(jiān)控和 Log 的設(shè)計(jì)，也成了我們方案設(shè)計(jì)的一部分。一般都會(huì)在方案后，加上必須的監(jiān)控的點(diǎn)和 Log 點(diǎn)，例如請(qǐng)求數(shù)，成功數(shù)，失敗數(shù)，各種異常數(shù)，極端邏輯執(zhí)行次數(shù)等等。

你應(yīng)該要意識(shí)到監(jiān)控和 Log 的重要性，而且應(yīng)該要花時(shí)間特別地設(shè)計(jì)。經(jīng)過良好設(shè)計(jì)的監(jiān)控和 Log，能發(fā)揮的價(jià)值，是那種憑感覺隨便加的監(jiān)控 Log 不可比擬的。

雙寫，雙讀驗(yàn)證

這招，新業(yè)務(wù)代碼用的不多。更多用于基礎(chǔ)系統(tǒng)或者核心系統(tǒng)的優(yōu)化和重構(gòu)上面。

而且有前置條件，需要一個(gè)操作可以重復(fù)執(zhí)行(例如只讀操作和冪等的數(shù)據(jù)操作)。

簡單來說，就是將新舊代碼，劃分為兩個(gè)流程(兩個(gè)接口)，上線到實(shí)際環(huán)境，然后在同個(gè)模塊里面調(diào)用。

一個(gè)請(qǐng)求進(jìn)來后，兩個(gè)流程分別執(zhí)行一次，逐字節(jié)做對(duì)比(例如 Memcmp)新舊流程的結(jié)果。新流程的結(jié)果只用于對(duì)比，返回得依舊是舊流程的結(jié)果，所以不影響線上業(yè)務(wù)。

如果對(duì)比失敗，就可能存在異常，要查找并解決，在實(shí)際環(huán)境跑了幾天后，都沒問題，就可以采用灰度的方式，進(jìn)一步放量。不過，一般業(yè)務(wù)不常使用，在基礎(chǔ)系統(tǒng)上使用比較多，這里就不展開了。

另外，對(duì)于客戶端，還有熱補(bǔ)丁機(jī)制，客戶端 Log 收集系統(tǒng)等。不過這種需要的開發(fā)量比較大，一個(gè)人不一定可以搞定，可能需要有個(gè)小團(tuán)隊(duì)來完成。

最后

軟件工程是個(gè)龐大的話題，我也沒能力論述這么大的話題。這里給大家講了個(gè)以前的故事，并且分享了我常用的一些低成本，但可以提高線上代碼質(zhì)量的方法，給大家參考參考。大家有好的做法，也歡迎在留言里分享出來。