经验分享：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的变量都必须在变量名前加上划线，

以上就是关于经验分享：Quora在对Python的使用以及其在实际开发过程中团队协作的代码管理的相关介绍，更多经验分享：Quora在对Python的使用以及其在实际开发过程中团队协作的代码管理相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对经验分享：Quora在对Python的使用以及其在实际开发过程中团队协作的代码管理有更深的了解和认识。