一個高質(zhì)量的代碼庫可以加快長期開發(fā)的速度，因?yàn)樗鼤沟玫f(xié)作和維護(hù)更加容易。在Quora，我們十分重視代碼庫的質(zhì)量。

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

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

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

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

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

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

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

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

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

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

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

提交后code review

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

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

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

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

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

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

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

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

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

code review任務(wù)分派

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

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

__reviewer__ = 'vanessa, kornel'

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

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

測試

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

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

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

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

代碼質(zhì)量指南

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

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

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

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

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

舊代碼的清理

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

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

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

Linting

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

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

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

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

結(jié)論

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

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