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自信地认为，未来还将开发出更多地工具和系统。
