经验分享：Quora在对Python的使用以及其在实际开发过程中团队协作的代码管理

首先，让我们来看看Quora网站开发中使用的主要技术：Web层和CMSHAProxy作为前端负载平衡服务器，反向代理服务器是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处理Longpolling和Push更新(不知道知乎用什么？)，Tornado是前FriendFeed技术团队开源的产品。由于Sphinx不能满足实时性的要求，Quora使用了自己开发的搜索引擎，只使用Thrift和Pythonunicode库，而不使用其他搜索引擎。Quora的搜索很特别，因为它需要提供更好的前缀索引，因为它需要关联输入内容并提供有效的提示(Prefixindexing)功能。Quora搜索的实现还是挺有技术含量的，后端查询请求的压力也不小(也许目前的并发请求量还没那么大)。做相关开发的朋友不妨仔细研究一下这个场景。如果一般框架相似，那么决定最终生成的因素很可能是细节。MySQL被用作数据持久层的存储方案，Memcached被用作Cache层。目前流行的NoSQL相关产品尚未使用。Quora这样做有自己的理由，用户量级没有达到百万的SNS网站完全没有必要使用NoSQL的东西。也许Quora将来也会启用。查理·奇弗，创始人(CharlieCheever)和亚当·德安杰洛在一起(AdamD'Angelo)之前都是Facebook，所以Quora的技术确实有很多Facebook基因。Quora的团队规模不大，估计只有十几个人在做技术。这么紧凑的团队用了这么多技术和产品，说明很多人都是多才多艺的。这是国内技术团队需要向外国同行学习的地方。Quora的技术管理经验：Quora的代码质量有四个原则。1.阅读和理解代码应该很简单——开发人员阅读代码的时间远远大于编写代码的时间。所以Quora应该尽量让代码简洁易懂，尽管写这样的代码可能需要比以前更长的时间。2.不同部分的代码应该有不同的质量要求——不同部分的代码对长期开发有不同的影响，因为它们有不同的生命周期、影响范围、被破坏的可能性、被破坏的后果大小和debug的难度。一般来说，不同的代码对产品迭代速度有不同的影响，所以平等对待所有代码显然不是最好的选择。3.维护代码质量的成本可以降低-开发自动化、更容易使用的开发工具、更好的流程和更好的开发人员可以降低维护代码质量的成本。4.整个代码库应该是一致的——整个代码库的一致性是非常重要的，尽管这意味着一些局部代码可能不会以最好的方式编写。缺乏一致性的代码库将使阅读、理解（参与第一点）、添加后续功能和使用自动化工具来改进代码更加困难。接下来，我将介绍Quora在开发过程中遵循四个原则的一些具体方法。代码提交后的相互审查（CodeReview）如果代码库中有代码变化，Quora将从六个方面进行同行审查-正确性（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写了一个命令行工具来帮助您*代码并要求审查。该工具允许开发人员在不修改之前提交的情况下正确运行Phabricatordiff。说了这么多，Quora对不同类型的变化有不同的审查要求。如果新代码可能造成严重后果，难以修复，Quora将要求提交前审查，而不是定期提交后审查。例如：1。涉及与用户隐私和匿名相关的代码；2。涉及与核心抽象类相关的代码，因为许多其他代码可能是基于它的；3。涉及可能导致停机的底层代码；提交前或提交后审查，这也与开发者的谨慎有关。如果任何开发人员在提交代码之前都想要求代码审查，以获得一些建议或意见，他们就完全有这样做的自由——尽管这很少发生。为了使代码审查顺利进行，将代码审查发送给正确的人，新代码应由对这一变化有充分了解的人进行审查。如果代码是由会维护这些代码的人负责的，那就更好了。显然，他们会有充分的理由和动机来最大限度地提高代码的长期可用性。Quora写了一个简单的系统，让开发者可以简单地表示名称模块/目录级别的代码所有权。他们只需要在文件的开头添加一个元标签。例如：__reviewer__=‘vanessa,kornel如有提交（commit）如果文件会改变，系统会读取标签，标签中标注的开发者会自动添加到comit的审查员名单中。此外，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“整顿周”（Cleanupweeks）清除这些糟粕。在这些整改周中，一些指定的团队——有时是整个公司——把所有的时间都花在了解旧代码上。这些定期活动减少了人们在“日常工作”和“整改工作”之间切换所需的时间和精力，也使旧代码的整改更加有趣，带来了更多的社会价值。有些代码比其他代码更容易纠正。当然，也有一些代码会对开发速度产生很大的影响。为了最好地利用每个人整改旧代码的时间，Quora将根据清除旧代码所需的时间和清除后对开发速度的影响，对每个代码模块的整改优先级进行排序。检错和优化代码（Linting）人们很容易低估偶尔不遵循代码语言规范（如代码注释或每行代码长度）的后果，但这些后果会叠加在一起。的确，时刻记住和遵循很多规范是很烦人的，尤其是规范越来越多的时候。因此，Quora并不感到惊讶，许多开发人员并不准备遵循这些规范。Quora开发了一种叫做qlint的工具，用于检查和优化公司内部代码，以减少实现这一目标的工作量。Qlint是基于flake8和pylint开发的智能小工具，可以识别文本结构和抽象语法树（AST）。这个工具使得Quora很容易在未来添加新的代码规则。例如，Quora规定，Python中所有private的变量都必须在变量名前加上划线，