首先來看一下Quora網站開發主要利用到的技術：

Web層與CMS

HAProxy作為前端負載均衡服務器，反向代理服務器是Nginx，Nginx后面則是Pylons(Pylons + Paste),承擔動態Web請求。

Webnode2與LiveNode這兩個內部系統承擔創建、管理內容的重任，Webnode2生成HTML、CSS與JavaScript，并且與LiveNode輕度耦合。LiveNode的作用用以顯示Web頁面內容。用Python、C++與JavaScript寫的。特別提到用到了jQuery與Cython。LiveNode有可能開源。

為什么用Python?

前面已經提到了一些Python相關的技術組件。有意思的是從Facebook出來的團隊居然用Python作為主要開發語言。Quora對此有所解釋:Facebook選擇PHP也并非是最佳選擇，而是有歷史原因。Quora技術團隊在考察了多個語言之后選擇的Python，當然理由有一大堆，總體看來，并非很激進。

通信處理

后端通信使用的是Facebook開源出來的Thrift，除了開發接口簡單之外，可能更為熟悉也是一個因素吧:)Comet服務器使用的是Tornado，用以處理Long polling以及Push 更新(不知道知乎用的什么?)，Tornado是前FriendFeed技術團隊開源的產品。

實時搜索

因為Sphinx不能滿足實時性方面的要求，Quora啟用了自己開發的搜索引擎，只使用了Thrift與Python Unicode庫，此外沒有用別的。Quora的搜索比較特別，因為要對輸入內容做關聯并且要做有效提示，所以需要提供更好的前綴索引(Prefix indexing)功能。

Quora搜索的實現還是挺有技術含量的，對后端的查詢請求壓力也不小(或許當前的并發請求量還沒那么大)。對這個場景，做相關開發的朋友不妨仔細研究一下。如果大體框架類似，那么決定最后生出的因素很可能是那些細節。

數據持久層

大量使用MySQL作為存儲方案，Memcached作Cache層。沒有使用當前比較火爆的NoSQL相關產品。Quora這樣做有自己的理由，用戶量級沒有達到百萬的SNS站點完全沒必要用NoSQL的東西。或許以后Quora也會啟用。

創始人查理·奇弗(Charlie Cheever)與亞當·德安杰洛(Adam D'Angelo)之前都在Facebook，所以，Quora的技術還真有不少Facebook的基因。Quora的團隊規模并不大，做技術的估計十余人而已，這么緊湊的團隊利用了這么多的技術與產品，可見很多人都是多面手了。這是國內技術團隊需要向國外同行學習的地方。

Quora 的技術管理經驗：

Quora 的代碼質量四項原則

1. 閱讀和理解代碼應該是簡單的 —— 開發者讀代碼的時間遠遠大于寫代碼的時間。因此Quora應該盡量使代碼簡潔易懂，盡管寫出那樣的代碼可能會需要比原來更長的時間。

2. 不同部分的代碼應該有不同的質量要求 —— 不同部分的代碼對于長期開發帶來的影響是不一樣的，因為它們有不同的生命周期、影響范圍、被破壞的可能性、破壞后帶來的后果大小，以及debug的難度。總體來說，不同的代碼對于產品迭代的速度的影響是不同的，因此對所有代碼都一視同仁顯然不是最佳選擇。

3. 維護代碼質量的成本是可以減少的 —— 開發自動化，更易用的開發工具，更好的流程，以及更好的開發者都能夠減少維護代碼質量的成本。

4. 整個代碼庫應有一致性 —— 整個代碼庫的一致性是很重要的，盡管這意味著某些局部代碼可能并沒有用最佳的方法去寫。一個缺乏一致性的代碼庫會使閱讀，理解（參加第1點），后續功能添加，和使用自動化工具來改進代碼都更加困難。

接下來，我將介紹一些在開發過程中 Quora 遵循著四項原則的具體方法。

代碼提交后的互相審查（Code Review）

如果代碼庫中有代碼變動，Quora會從 6 方面來同行審查 —— 正確性（correctness）、代碼封裝（privacy）、 性能（performance）、架構（architecture）、可重用性（reusability）、代碼風格（style）。閱讀代碼是代碼審查中不可或缺的一環，因此實施代碼審查制度對于增加代碼可讀性也無疑是有利的。

但不幸的是，代碼審查也會拖慢開發進程。例如代碼提交前的互相審查這個業界常規，代碼在被提交到代碼庫之前必須由同伴審閱并由作者完成改進。每輪審查可能會持續兩天，然后常常有兩到三輪審閱，這意味著代碼作者會經常將浪費大半個星期在代碼審閱的工作上。

在 Quora，Quora并不進行代碼提交前的審查。即，代碼會先上線，然后才由某些同事來進行審閱。為了讓你對Quora的工作規模有個概念，昨天Quora有48個開發者總共進行了 187 次代碼提交（commit）。Quora認為代碼后審閱是一項很好的舉措，因為它讓開發者們從不必要的代碼審閱的牢籠中解放出來，可以先去完成其它的工作。這樣，審閱者們也可以挑他們方便的時候來閱讀這些代碼，以免被別人催促著完成這項工作。Quora的流程希望Quora在一周內完成代碼審閱工作就可以了，但Quora大多數都會在  1  至  2  天內進行審閱。這個“一周”的長度是在仔細討論后定下的 —— 它既長到足夠審閱者們自由安排審閱時間，也短到可以及時阻止低質量代碼可能帶來的，被其他人閱讀并使用的后果。實際操作中，Quora也考慮到了許多開發者會有一個以“星期”為周期而安排的工作時間表。

Quora能實施代碼提交后審閱這項舉措，也是因為Quora對 Quora 的每個開發者都加以信任，畢竟Quora只雇傭最好的開發者，也給予了他們最好的工具和最用心的培訓。這也促使Quora寫下一些很好的測試來達到很高的代碼覆蓋率，這讓Quora在任何代碼審閱之前都可以自己檢閱代碼的正確性。除此以外，Quora使用 Phabricator 這個非常棒，配置自由度也相當高的代碼審查工具。Quora對 Phabricator 這個工具做了一些修改，讓它能更好的為Quora提交后審查的流程服務。例如，Quora寫了一個命令行工具來幫助大家上線代碼并要求審閱。這個工具會讓開發者在不對之前的提交進行任何修改的同時讓 Phabricator 的 diff 能夠正確運行。

說了這么多，Quora對不同種類的改動有著不同的審閱要求。如果新代碼有可能會造成嚴重的后果，并且修復起來很難的話，Quora會要求對它進行提交前審查，而不是常規的提交后審查。比如：

1. 涉及與用戶隱私和匿名相關的代碼；
2. 涉及了與一個核心抽象類有關的代碼，因為很多其它代碼可能基于它；
3. 涉及了可能會造成宕機的底層代碼；
提交前還是提交后要求審查，這也跟開發者的謹慎程度有關。如果任何開發者想要在提交代碼前要求代碼審查，以此來獲得一些建議或意見的話，他們完全有這么做的自由 —— 盡管這很少發生。

把代碼審閱發給正確的人

為了使代碼審查進行得順利，新代碼應該由對于這個改變有著充分的認知的人來審查。如果代碼是由將會維護這些代碼的人負責那就更好了，顯然他們將會有很充分的理由和動機，來使代碼長期的可用性達到最佳。

Quora寫了一個簡單的系統，讓開發者們可以簡單地表名模塊/目錄級別的代碼歸屬，它們只需要在文件的開頭加一個元標簽就可以了。例如：

__reviewer__ = ‘vanessa, kornel’

如果有個提交（commit）會改變某個文件的話，這個系統會讀取這個標簽，這個標簽里標明的開發者會被自動添加到這個 commit 的審閱者名單里。除此以外，Quora也有其它的關于代碼審閱者的規則，例如對于所有設置了 A/B 測試的 commit，都會有一個數據分析師——如果原來沒有的話——被自動加到審閱名單里。事實上，Quora的工具也可以很簡單地添加其它的關于代碼審閱人的規則。例如，如果Quora想的話，可以把新雇員的所有 commit 都發送給他們的導師。

有一個智能的審閱分發系統，把代碼審閱發送給正確的人，減少了開發者們尋找代碼審閱者的煩惱，并確保能找到最適合的人來審閱每一份代碼。

測試

測試是開發流程中很重要的一環。Quora寫了很多單元測試、功能測試、UI 測試來達到高代碼覆蓋率。有一個完整的單元測試，可以讓開發者快速平行地完成新代碼，而不必擔心破壞掉已有的功能。Quora花了很多時間來制作Quora的測試框架（基于 nosetests ），目標是簡單、快速、易用，使寫測試的工作量盡可能低。

Quora也開發了許多自動化測試的工具。正如之前一篇探討Quora持續部署系統的文章所講的一樣，Quora所有的代碼在上線之前都在一個中心服務器上完成測試。這個測試服務器有著高并行的特性，因此即使跑完Quora所有的測試也只需要不到5分鐘。這么快速的系統就是為了鼓勵開發者們盡可能多地寫測試和進行測試。Quora有一個叫“本地測試（test-local）”的工具，來自動找到和執行和新增代碼有關的測試。為了更好地使用這個工具，Quora的測試必須要模塊化（這也在一個測試失敗了的情況下，幫助開發者們快速找到bug并修復）。為了確保這個目的和一些其它的關于測試代碼的重要性質，Quora有一份描述測試代碼書寫規范的共享文件。這些原則在代碼審閱時被嚴格執行。

和代碼審閱類似，Quora對于不同種類的改動有不同的測試標準。如果新改動有可能帶來嚴重后果和修復成本的話，Quora會要求更高的代碼覆蓋率。

所有的這些加在一起，使Quora寫測試的意義最大化，以此減少長期的開發成本。

代碼質量指導

Quora非常熱衷于共享代碼質量指導，這幫助Quora：

1. 更好地培訓新來的開發者；
2. 更好地在整個團隊里共享Quora的經驗和智慧；
3. 設立共同的標準來提高代碼庫的一致性；
4. 減少開發和審閱環節的工作量。例如，在每個審閱中都討論一下每行代碼是80個還是100個字符是沒意義的。Quora可以就討論這個問題一次，然后在所有今后的代碼中都使用這個標準。
除了每種語言自身的語句規范之外，Quora也有更抽象的一些代碼規范，例如關于如何寫出好的測試或是如何架構代碼模塊，來幫助減少代碼的閱讀時間。這些規范并不是一成不變的。在Quora逐漸對各種權衡有了更深的理解的過程中，Quora也會改變這些規范來達到利益最大化。Quora也有大型代碼重構的工具（部分是諸如例如 codemod 之類的開源工具，其它的是Quora自己開發的），以在Quora改變了某項規范之后回過頭去重構所有的舊代碼。

整頓舊代碼

一個快速前進的團隊會嘗試很多新事物，自然而然，它們之中某些很好，而某些則不盡如人意。因此，一個快速前進的公司的代碼庫里肯定會有很多沉淀下來的糟粕，即那些實際上大家不再使用，卻留在那里使許多事情變得更復雜的代碼。清楚這些糟粕，保持代碼庫的簡潔，也會提高開發速度。
Quora定期組織“整頓周（Cleanup weeks）”來清除這些糟粕。在這些整頓周里，一些指定團隊——有時也會是整個公司——把所有的時間都花在清楚那些不用的舊代碼上。這些定期活動減少了大家在“常規工作”和“整頓工作”中切換所需花費的時間和精力，也讓整頓舊代碼變得更為有趣，帶來更多的社交價值。

部分代碼比其它的更加容易整頓，當然也有部分代碼，整頓起來會對開發速度有極大的影響。為了最好地利用大家整頓舊代碼的時間，Quora會基于清除它們所需耗費的時間，和清除后它們對開發速度帶來的影響，對各個代碼模塊的整頓優先級進行排序。

代碼查錯與優化（Linting）

人們很容易低估偶爾不遵循代碼語言規范（例如代碼注釋或每行代碼的長度）的后果，但這些后果是會疊加起來的。確實，時時記得并遵循很多規范是很惱人的，特別是規范越來越多的時候。因此，Quora并不驚訝，很多開發者并不準備遵循這些規范。

Quora開發了一個公司內部代碼查錯和優化的工具，叫做 qlint，來減少達成這一目標的工作量。Qlint 是基于 flake8 和 pylint開發的智能小工具，能識別文本結構和抽象語法樹（AST）。這個工具讓Quora未來往里面添加新的代碼規則變得很容易。例如，Quora規定在Python里所有private的變量都必須在變量名前加下劃線，因而Quora在 qlint 里加了這一條規則來查找所有不符合這一規范的代碼。

Quora把 qlint 整合進了許多其它開發工具，因此開發者們不必特別來關注 qlint 指出的各項問題。對于剛剛起步的開發者們，Quora把 qlint 整合進了最流行的一些編輯器，例如 Vim、Emacs 和 Sublime，并在開發者違反了代碼規范的時候提供可視化的提示。Qlint 也整合在了提交代碼的流程里，并在任何人想要提交代碼的時候以一種互動化的方式運行。事實上，取決于 commit 具體違反了哪條規則，這個工具甚至可能阻止代碼部署。Quora也把Quora的代碼規范文檔整合在了這個工具里，因此開發者每違反一條規則，qlint 都會給出一個鏈接指向文檔里的那個規則條目。Quora的 Phabricator 也被配置成使用qlint。這樣，由于所有的錯誤都由 qlint 以可視化的方式指出了，代碼審閱變得更為簡單。
所有這些改進都提高了Quora代碼庫的一致性，并使Quora能夠以最小的成本提高代碼質量。

總結

就像這篇文章中指出的那樣，Quora 十分嚴謹認真地對待代碼質量。Quora對待這個問題很腳踏實地。Quora設計并開發了各種工具、系統和流程，來保持并增強Quora長期的開發效率。在Quora此時達到良好平衡的同時，Quora的團隊也在不斷地擴大和成長，因此Quora自信地認為，未來還將開發出更多地工具和系統。