一個(gè)高質(zhì)量的代碼庫(kù)可以加快長(zhǎng)期開(kāi)發(fā)的速度，因?yàn)樗鼤?huì)使得迭代、協(xié)作和維護(hù)更加容易。在Quora，我們十分重視代碼庫(kù)的質(zhì)量。

除 了會(huì)取得收益之外，要維護(hù)高質(zhì)量的代碼，會(huì)帶來(lái)一大筆間接費(fèi)用，還會(huì)犧牲實(shí)際開(kāi)發(fā)周期。很多人發(fā)現(xiàn)，實(shí)際產(chǎn)生的收益很難抵消這一間接費(fèi)用，這時(shí)人們會(huì)面臨 兩個(gè)選擇：要么以低質(zhì)量代碼提升開(kāi)發(fā)速度，要么維護(hù)高質(zhì)量代碼而犧牲開(kāi)發(fā)速度。而對(duì)于初創(chuàng)公司來(lái)說(shuō)，他們希望開(kāi)發(fā)速度能快一些，所以就不得不使用低質(zhì)量的 代碼。

我們開(kāi)發(fā)了一系列工具和流程，這樣就可以在維護(hù)高質(zhì)量代碼庫(kù)的同時(shí)，提升開(kāi)發(fā)的速度。在這篇文章中，我們將會(huì)介紹關(guān)于保證代碼質(zhì)量的一些方法，以及一些平衡這兩方面的具體案例。

維護(hù)高質(zhì)量代碼的目標(biāo)

維護(hù)高質(zhì)量代碼主要的好處在于能夠長(zhǎng)期推動(dòng)開(kāi)發(fā)速度，這也是我們所關(guān)注的重點(diǎn)。通過(guò)編寫清晰代碼而產(chǎn)生的短期成本，就可以換來(lái)長(zhǎng)期的收益。

記住這一點(diǎn)，然后下面是四點(diǎn)基本原則，我們發(fā)現(xiàn)對(duì)代碼質(zhì)量非常有幫助：

Quara的代碼質(zhì)量基本原則

1. 代碼的閱讀和理解都要很容易——現(xiàn)在的情況是更多的時(shí)間用在了代碼的閱讀上，而不是代碼的編寫上。實(shí)際上，應(yīng)該把閱讀的時(shí)間減少，即便這樣意味著需要花費(fèi)更多的時(shí)間來(lái)寫代碼。

2. 代碼的不同部分需要有不同的質(zhì)量標(biāo)準(zhǔn)——不同的代碼行需要有不同的使用時(shí)間、范圍、被破壞的風(fēng)險(xiǎn)、被破壞后造成的成本及其修復(fù)的成本，等等?？傮w來(lái)講，這些對(duì)長(zhǎng)期迭代速度的影響不同，所以執(zhí)行一個(gè)統(tǒng)一的質(zhì)量標(biāo)準(zhǔn)是不合理的。

3. 代碼質(zhì)量的間接費(fèi)用是可以縮減的——維護(hù)高質(zhì)量成本的間接費(fèi)用一般是可以節(jié)省的，這可以通過(guò)使用自動(dòng)化、更好的工具、更好的流程和培訓(xùn)更優(yōu)質(zhì)的開(kāi)發(fā)人員來(lái)實(shí)現(xiàn)。

4. 代碼庫(kù)一致性很重要——保持整個(gè)代碼庫(kù)的一致性是十分有價(jià)值的，即便這意味著有一部分代碼不能是***的。一個(gè)不一致的代碼庫(kù)是很難閱讀和理解的（見(jiàn)***點(diǎn)），也很難編寫，很難通過(guò)自動(dòng)化工具進(jìn)行優(yōu)化。

下面，我來(lái)介紹幾個(gè)我們將這幾點(diǎn)原則用于實(shí)際開(kāi)發(fā)的例子。

提交后code review

我們代碼庫(kù)的代碼變更需要從六個(gè)維度進(jìn)行評(píng)估——正確性、隱私、性能、架構(gòu)、復(fù)用性和風(fēng)格。讀代碼是code review的關(guān)鍵部分，所以說(shuō)，code review在提升代碼可讀性方面起著至關(guān)重要的作用。

但 是有一點(diǎn)不好的是，code review同樣會(huì)減緩開(kāi)發(fā)速度。比如說(shuō)，提交前code review在行業(yè)中目前是比較常見(jiàn)的，其中代碼必須在推送之前就進(jìn)行審查和修改。這樣的話，即使是每一輪審查只需要2天的時(shí)間，這樣重復(fù)2-3輪，也會(huì) 耽誤開(kāi)發(fā)人員一周的時(shí)間，這是嚴(yán)重的時(shí)間浪費(fèi)。

在Quora，我們主要做的是提交后code review。也就是說(shuō)，代碼首先進(jìn)入生產(chǎn)階段， 然后再找人進(jìn)行code review。為了讓你對(duì)這一工作的規(guī)模有個(gè)認(rèn)識(shí)，舉個(gè)例子，昨天我們48個(gè)人總共推送了187次代碼。提交后review是很好的辦法，因?yàn)樗夥帕碎_(kāi) 發(fā)人員，可以去做其他的工作。code review人員也可以更好的管理自己的時(shí)間，可以在他們方便的時(shí)候做代碼審查，而不是非得匆忙的完成這一工作，以便不影響其他人的工作。過(guò)程合理的話， 預(yù)計(jì)代碼審查一周內(nèi)可以完成，而實(shí)際上大部分情況下，一到兩天就可以完成。之所以說(shuō)一周的時(shí)間，也是經(jīng)過(guò)仔細(xì)考慮的，因?yàn)橐恢茏銐蜷L(zhǎng)，可以允許審查人員靈 活安排，而一周的時(shí)間又有點(diǎn)短，因?yàn)樗枰獙⒉缓媒Y(jié)果的影響最小化，比如說(shuō)有人讀了代碼之后將不好的代碼在整個(gè)代碼庫(kù)中進(jìn)行傳播。實(shí)際還有這樣一層原因， 很多的開(kāi)發(fā)人員都是按周進(jìn)行個(gè)人工作安排的。

我們之所以可以做提交后code review，是因?yàn)槲覀兿嘈盼覀兊拿恳晃婚_(kāi)發(fā)人員，我們選擇的都是***秀的人才，并且我們?cè)谒麄兊拇a質(zhì)量培訓(xùn)/工具方面投入了大量資金。這也督促我們 對(duì)代碼進(jìn)行更好的測(cè)試，而好的測(cè)試能幫助檢測(cè)代碼的準(zhǔn)確性，甚至在任何code review工作開(kāi)始之前就可以檢測(cè)。對(duì)此，我們采用的是Phabricator， 一個(gè)穩(wěn)健的、高配置的審查工具。我們對(duì)它做了幾點(diǎn)改進(jìn)，這樣就能與我們的提交后code review工作流更好的配合。比如說(shuō)，我們構(gòu)建了一個(gè)命令行工具，可以將代碼推向生產(chǎn)階段，并提出代碼審查請(qǐng)求。有了該工具，Phabricator的 diff就可以繼續(xù)工作，而無(wú)需去修復(fù)那些commits。

所有這些說(shuō)明，對(duì)于不同類型的代碼問(wèn)題，我們有不同的代碼審查標(biāo)準(zhǔn)。如果說(shuō)我們事先發(fā)現(xiàn)了某一個(gè)潛在錯(cuò)誤，問(wèn)題比較大，可能會(huì)帶來(lái)很大影響，那么我們會(huì)轉(zhuǎn)而執(zhí)行提交前審查，而不是平常的提交后審查。這方面的幾個(gè)例子：

1. 涉及用戶隱私和匿名的代碼。

2. 涉及核心的抽象類（abstraction），因?yàn)楹芏嗥渌拇a都可能依賴于它。

3. 涉及基礎(chǔ)設(shè)施的某些部分，其有些錯(cuò)誤可能會(huì)導(dǎo)致宕機(jī)的風(fēng)險(xiǎn)。

當(dāng)然這還取決于開(kāi)發(fā)人員如何決策——如果他們想要對(duì)某些代碼進(jìn)行提交前審查，從而從中獲取更多想法，這也是可以的，而不用非得采用平常的提交后code review，只不過(guò)這種情況比較少見(jiàn)。

code review任務(wù)分派

為了做好code review，每一個(gè)變更都應(yīng)該由有著相關(guān)經(jīng)驗(yàn)的人員來(lái)審查。如果這些code review人員能負(fù)責(zé)“維護(hù)”這些他們審查過(guò)的代碼的話那就更好了，這樣他們可以獲得一定物質(zhì)報(bào)酬，進(jìn)而形成長(zhǎng)期的交易關(guān)系。

我們之前實(shí)施了一個(gè)簡(jiǎn)單的系統(tǒng)，其模塊和目錄層級(jí)代碼的“所有權(quán)”只需要在文件開(kāi)頭賦予一個(gè)元標(biāo)簽（meta tag）就可以指定了。比如：

__reviewer__ = 'vanessa, kornel'

如 果某commit要對(duì)文件做一些修改，其reviewer就會(huì)根據(jù)文件（或結(jié)構(gòu)樹(shù)【ancestor tree】），進(jìn)行分析，并自動(dòng)作為reviewer添加到commit中。我們針對(duì)code review任務(wù)的分派或者說(shuō)路由選擇還有一些其他的規(guī)則，比如說(shuō)，如果沒(méi)有reviewer的話，一個(gè)數(shù)據(jù)科學(xué)家可自動(dòng)作為一個(gè)reviewer添加到 啟動(dòng)A/B測(cè)試的commit中。實(shí)際上我們已經(jīng)搭建了一些工具，可以讓我們更容易的制定更多這類自定義的“路由”規(guī)則。舉個(gè)例子，如果我們想做，那就很 容易就能增加一個(gè)規(guī)則，可以將某一個(gè)新任務(wù)所有的commits都路由指派給相應(yīng)的人員。

這樣的一個(gè)智能系統(tǒng)，將所有的commits都分配給合適的人員進(jìn)行代碼審查，能有效減輕開(kāi)發(fā)人員的負(fù)擔(dān)，否則他們還需要四處尋找合適的審查人員，還要確保大部分的審查人員否能認(rèn)真審查每條commit。

測(cè)試

測(cè)試對(duì)我們的開(kāi)發(fā)流程來(lái)說(shuō)是非常重要的一步，我們寫了很多的單元測(cè)試、功能測(cè)試和UI測(cè)試代碼，覆蓋很大的測(cè)試范圍。而一個(gè)綜合性測(cè)試可以讓開(kāi)發(fā)人員并行工作，工作進(jìn)行的更快，而不用擔(dān)心會(huì)破壞現(xiàn)有功能。我們投入了大量時(shí)間來(lái)制定測(cè)試框架（建立在nosetests之上），使其容易使用、可快速應(yīng)用，從而降低編寫測(cè)試代碼的間接費(fèi)用。

我們還開(kāi)發(fā)了幾項(xiàng)工具，可以實(shí)現(xiàn)測(cè)試的自動(dòng)化。我們之前發(fā)布了一篇關(guān)于“持續(xù)集成系統(tǒng)” 的文章，描述了一個(gè)中心服務(wù)器，可以在部署任何新代碼之前運(yùn)行所有測(cè)試。該測(cè)試服務(wù)器可以并行運(yùn)行，這樣的話運(yùn)行所有的測(cè)試只需要不到5分鐘的時(shí)間。這樣 的快速運(yùn)轉(zhuǎn)可以激勵(lì)人們經(jīng)常性的編寫和執(zhí)行測(cè)試程序。我們有一個(gè)叫做“test-local”的工具，只能識(shí)別和執(zhí)行代碼工作副本的測(cè)試變更相關(guān)的測(cè)試文 件。為了能做的更好，我們的測(cè)試還需要進(jìn)行模塊化（這能進(jìn)一步幫我們?cè)跍y(cè)試失敗的時(shí)候進(jìn)行快速調(diào)試）。為了確保好的測(cè)試代碼能得到期望的性能，我們維護(hù)了 一個(gè)共享文檔，描述了編寫測(cè)試代碼相關(guān)的***實(shí)踐。這些指導(dǎo)方針在代碼審查過(guò)程中會(huì)被嚴(yán)格執(zhí)行。

同code review一樣，我們對(duì)不同類型的變更也有不同的測(cè)試標(biāo)準(zhǔn)，對(duì)測(cè)試范圍有更高的要求，尤其是變更成本很高的情況。

所有這些系統(tǒng)使得我們能夠從寫測(cè)試代碼的過(guò)程中獲取***收益，可以以很小的間接費(fèi)用節(jié)省很多的開(kāi)發(fā)周期。

代碼質(zhì)量指南

我們非常熱衷于共享代碼質(zhì)量標(biāo)準(zhǔn)的指南，它可以幫我們做很多事情：

① 作為新開(kāi)發(fā)人員培訓(xùn)的很好的工具。

② 與整個(gè)團(tuán)隊(duì)分享每個(gè)人的智慧和***實(shí)踐。

③ 降低開(kāi)發(fā)和代碼審查過(guò)程的間接費(fèi)用。比如說(shuō)，我們討論一次就可以得出一些有價(jià)值的結(jié)論的話，那么再在每次code review時(shí)討論代碼行應(yīng)該是80個(gè)字符串還是100個(gè)字符串就完全沒(méi)有意義了。

除了針對(duì)不同語(yǔ)言的語(yǔ)法風(fēng)格指南，我們還有一些針對(duì)抽象事務(wù)的指導(dǎo)，比如如何寫一個(gè)好的測(cè)試用例，或者如何做出更好的模塊架構(gòu)，從而提高工作效率。這些指南不是一成不變的，是隨著我們對(duì)不同的過(guò)程有了更深的理解而不斷發(fā)展的。我們還有很多重構(gòu)的工具（一些開(kāi)源工具比如codemod，還有一些內(nèi)部開(kāi)發(fā)的工具），以備我們改變指南的時(shí)候需要重新“修改”所有的歷史代碼。

舊代碼的清理

一 個(gè)快速發(fā)展的團(tuán)隊(duì)會(huì)嘗試很多不同的工具，當(dāng)然其中不乏有一些可以用而有一些不可用。到***，任何一家快速發(fā)展的公司，隨著時(shí)間的推移其代碼庫(kù)都會(huì)開(kāi)發(fā)很多 多余的東西，而這些可能永遠(yuǎn)都不會(huì)再用，放在那里只會(huì)使很多東西變得混亂。清理這些廢棄代碼可以使得代碼庫(kù)更健康的運(yùn)行，還能提升開(kāi)發(fā)的速度。

我們會(huì)定期組織“清理周”，對(duì)這些多余代碼進(jìn)行清理。在清理周內(nèi)，某一些團(tuán)隊(duì)或者有時(shí)會(huì)發(fā)動(dòng)整個(gè)公司專門來(lái)清理舊代碼。這種定期的清理模式可以降低在“正常工作”和“清理工作”之間來(lái)回轉(zhuǎn)換的成本，還能使得清理工作更加社交化，更加有樂(lè)趣。

代碼庫(kù)有些部分會(huì)比其他部分相對(duì)更好清理一些。同樣地，清理代碼庫(kù)的不同部分會(huì)對(duì)開(kāi)發(fā)速度產(chǎn)生不同的影響。為了能更好的利用好舊代碼清理的時(shí)間，我們?cè)诳紤]成本的基礎(chǔ)上優(yōu)化了相關(guān)模塊，來(lái)進(jìn)行清理工作，以及衡量清理工作對(duì)未來(lái)開(kāi)發(fā)速度的影響。

Linting

我 們很可能會(huì)低估在某一實(shí)例中不遵循上述代碼質(zhì)量指南（比如說(shuō)docstring的格式或代碼行長(zhǎng)度）所造成的成本，但事實(shí)上成本的確是增加了。同時(shí)，要記 住各種各樣的規(guī)則并應(yīng)用，也是一件很煩的事情，尤其是規(guī)則還在不斷增加。最終造成的結(jié)果就是，很多人都選擇不再遵循這些指導(dǎo)方針。

我們開(kāi)發(fā) 了一個(gè)內(nèi)部的linter，叫做qlint，可以相應(yīng)減輕一些上述困擾。qlint是一個(gè)很智能的linter，可以讀懂文本結(jié)構(gòu)以及AST，是基于 flake8和pylint的。它旨在使得未來(lái)增加自定義的lint規(guī)則變得更容易。比如說(shuō)，我們其中一個(gè)做法是Python中任何一個(gè)“私有”變量都需 要進(jìn)行突出強(qiáng)調(diào)，所以我們?cè)趒lint中新增了一個(gè)規(guī)則，那就是可以檢測(cè)出這類私有變量中任何不合理的地方。

我們還將qlint與很多系統(tǒng) 集成起來(lái)，提供無(wú)縫的開(kāi)發(fā)環(huán)境，這樣人們就不必親自盯著lint錯(cuò)誤。對(duì)于新手來(lái)說(shuō)，qlint是一個(gè)與我們常用的文本編輯器——Vim，Emacs和 Sublime——充分集成的工具，可以在規(guī)則被破壞的情況下提供可視的反饋（紅色標(biāo)記）。它還與我們的推送流程集成在了一起，任何人在進(jìn)行code推送 的時(shí)候都可以運(yùn)行qlint（以互動(dòng)的方式）。而實(shí)際上，如果某項(xiàng)規(guī)則被commit打破，它有可能就會(huì)影響到部署工作。我們還將我們的風(fēng)格指南與 qlint集成起來(lái)，這樣對(duì)每一個(gè)lint錯(cuò)誤，qlint都可以給出一個(gè)超鏈接，指向相關(guān)風(fēng)格指導(dǎo)的相應(yīng)規(guī)則。我們的Phabricator也可以用 qlint。通過(guò)這種方式，所有被qlint找到的錯(cuò)誤都被明顯的標(biāo)記出來(lái)，這樣他們的代碼審查工作就變得相當(dāng)容易了。

所有這些都幫我們實(shí)現(xiàn)了以很小的成本就能提升代碼的一致性和質(zhì)量。

結(jié)論

就 像文章中所說(shuō)的那樣， Quora對(duì)代碼的重視程度是很高的。我們講求務(wù)實(shí)主義，搭建了很多好的系統(tǒng)、工具和流程，能幫我們?cè)鰪?qiáng)并維護(hù)長(zhǎng)期開(kāi)發(fā)的生產(chǎn)效率。今天我們努力維持一個(gè) 良好的平衡，我們的團(tuán)隊(duì)也在不斷成長(zhǎng)和發(fā)展，所以我們相信，未來(lái)我們還將生產(chǎn)更多的工具和系統(tǒng)。

如果你想幫我們搭建這樣的系統(tǒng)，或者想成為我們強(qiáng)大開(kāi)發(fā)團(tuán)隊(duì)的一份子，幫助我們以這樣一種務(wù)實(shí)的、深刻的方式提升代碼質(zhì)量，那么歡迎加入我們。