Quora 是如何做到高质量的快速开发的?

【伯乐在线导读】:高质量的代码库可以促进开发速度,对产品迭代、开发协作和维护都大有裨益。不过维护代码质量也同时会带来许多额外开支,并拖慢开发进程。所以很多人认为,要么忽略代码质量快速开发,要么在维护代码质量的同时接受缓慢的开发速度。本文让大家看看 Quora 是如何做到两全其美的实践。


从长远来说,高质量的代码库会促进开发速度,因为它会使软件的迭代、协作和维护都更为简单。在Quora,我们认真而严谨地对待代码质量。

但在这些益处之外,维护代码质量也同时会带来许多额外开支,并拖慢开发进程。很多人都觉得在这两者之间抉择非常困难,因为他们都认为这是个非此即彼的选择:要么忽略代码质量快速开发,要么在维护代码质量的同时接受缓慢的开发速度。由于快速的产品迭代对于初创企业最为重要,因此很多人都认为初创者一定只能生产低质量代码。

然而,我们利用设计优化开发工具和开发流程的方法,解决了这个两难的问题。这些优化使我们能进行高质量的快速开发。在这篇文章里,我们将会介绍一些让我们达到两全其美的,维持代码质量的方法和实践。

维护代码质量的目的

The main benefit of maintaining high code quality is the long-term boost to development speed, so this is what we optimize for and focus on. We just need to trade-off those long-term gains with the short-term costs of writing cleaner code upfront.

维护代码质量的最大好处就是它会大大增进长期开发的速度。这是我们进行所有优化的目标和重点。我们只是要提前处理好这些长期效用,和它所带来的短期增加的工作量的关系。

明确了目标之后,这是我们认为最有用的,关于代码质量的四项原则:

Quora 的代码质量四项原则

1. 阅读和理解代码应该是简单的 —— 开发者读代码的时间远远大于写代码的时间。因此我们应该尽量使代码简洁易懂,尽管写出那样的代码可能会需要比原来更长的时间。

2. 不同部分的代码应该有不同的质量要求 —— 不同部分的代码对于长期开发带来的影响是不一样的,因为它们有不同的生命周期、影响范围、被破坏的可能性、破坏后带来的后果大小,以及debug的难度。总体来说,不同的代码对于产品迭代的速度的影响是不同的,因此对所有代码都一视同仁显然不是最佳选择。

3. 维护代码质量的成本是可以减少的 —— 开发自动化,更易用的开发工具,更好的流程,以及更好的开发者都能够减少维护代码质量的成本。

4. 整个代码库应有一致性 —— 整个代码库的一致性是很重要的,尽管这意味着某些局部代码可能并没有用最佳的方法去写。一个缺乏一致性的代码库会使阅读,理解(参加第1点),后续功能添加,和使用自动化工具来改进代码都更加困难。

接下来,我将介绍一些在开发过程中 Quora 遵循着四项原则的具体方法。

代码提交后的互相审查(Code Review)

如果代码库中有代码变动,我们会从 6 方面来同行审查 —— 正确性(correctness)、代码封装(privacy)、 性能(performance)、架构(architecture)、可重用性(reusability)、代码风格(style)。阅读代码是代码审查中不可或缺的一环,因此实施代码审查制度对于增加代码可读性也无疑是有利的。

但不幸的是,代码审查也会拖慢开发进程。例如代码提交前的互相审查这个业界常规,代码在被提交到代码库之前必须由同伴审阅并由作者完成改进。每轮审查可能会持续两天,然后常常有两到三轮审阅,这意味着代码作者会经常将浪费大半个星期在代码审阅的工作上。

在 Quora,我们并不进行代码提交前的审查。即,代码会先上线,然后才由某些同事来进行审阅。为了让你对我们的工作规模有个概念,昨天我们有48个开发者总共进行了 187 次代码提交(commit)。我们认为代码后审阅是一项很好的举措,因为它让开发者们从不必要的代码审阅的牢笼中解放出来,可以先去完成其它的工作。这样,审阅者们也可以挑他们方便的时候来阅读这些代码,以免被别人催促着完成这项工作。我们的流程希望我们在一周内完成代码审阅工作就可以了,但我们大多数都会在  1  至  2  天内进行审阅。这个“一周”的长度是在仔细讨论后定下的 —— 它既长到足够审阅者们自由安排审阅时间,也短到可以及时阻止低质量代码可能带来的,被其他人阅读并使用的后果。实际操作中,我们也考虑到了许多开发者会有一个以“星期”为周期而安排的工作时间表。

我们能实施代码提交后审阅这项举措,也是因为我们对 Quora 的每个开发者都加以信任,毕竟我们只雇佣最好的开发者,也给予了他们最好的工具和最用心的培训。这也促使我们写下一些很好的测试来达到很高的代码覆盖率,这让我们在任何代码审阅之前都可以自己检阅代码的正确性。除此以外,我们使用 Phabricator 这个非常棒,配置自由度也相当高的代码审查工具。我们对 Phabricator 这个工具做了一些修改,让它能更好的为我们提交后审查的流程服务。例如,我们写了一个命令行工具来帮助大家上线代码并要求审阅。这个工具会让开发者在不对之前的提交进行任何修改的同时让 Phabricator 的 diff 能够正确运行。

说了这么多,我们对不同种类的改动有着不同的审阅要求。如果新代码有可能会造成严重的后果,并且修复起来很难的话,我们会要求对它进行提交前审查,而不是常规的提交后审查。比如:

  • 1. 涉及与用户隐私和匿名相关的代码;
  • 2. 涉及了与一个核心抽象类有关的代码,因为很多其它代码可能基于它;
  • 3. 涉及了可能会造成宕机的底层代码;

提交前还是提交后要求审查,这也跟开发者的谨慎程度有关。如果任何开发者想要在提交代码前要求代码审查,以此来获得一些建议或意见的话,他们完全有这么做的自由 —— 尽管这很少发生。

把代码审阅发给正确的人

为了使代码审查进行得顺利,新代码应该由对于这个改变有着充分的认知的人来审查。如果代码是由将会维护这些代码的人负责那就更好了,显然他们将会有很充分的理由和动机,来使代码长期的可用性达到最佳。

我们写了一个简单的系统,让开发者们可以简单地表名模块/目录级别的代码归属,它们只需要在文件的开头加一个元标签就可以了。例如:

__reviewer__ = ‘vanessa, kornel’

如果有个提交(commit)会改变某个文件的话,这个系统会读取这个标签,这个标签里标明的开发者会被自动添加到这个 commit 的审阅者名单里。除此以外,我们也有其它的关于代码审阅者的规则,例如对于所有设置了 A/B 测试的 commit,都会有一个数据分析师——如果原来没有的话——被自动加到审阅名单里。事实上,我们的工具也可以很简单地添加其它的关于代码审阅人的规则。例如,如果我们想的话,可以把新雇员的所有 commit 都发送给他们的导师。

有一个智能的审阅分发系统,把代码审阅发送给正确的人,减少了开发者们寻找代码审阅者的烦恼,并确保能找到最适合的人来审阅每一份代码。

测试

测试是开发流程中很重要的一环。我们写了很多单元测试、功能测试、UI 测试来达到高代码覆盖率。有一个完整的单元测试,可以让开发者快速平行地完成新代码,而不必担心破坏掉已有的功能。我们花了很多时间来制作我们的测试框架(基于 nosetests ),目标是简单、快速、易用,使写测试的工作量尽可能低。

我们也开发了许多自动化测试的工具。正如之前一篇探讨我们持续部署系统的文章所讲的一样,我们所有的代码在上线之前都在一个中心服务器上完成测试。这个测试服务器有着高并行的特性,因此即使跑完我们所有的测试也只需要不到5分钟。这么快速的系统就是为了鼓励开发者们尽可能多地写测试和进行测试。我们有一个叫“本地测试(test-local)”的工具,来自动找到和执行和新增代码有关的测试。为了更好地使用这个工具,我们的测试必须要模块化(这也在一个测试失败了的情况下,帮助开发者们快速找到bug并修复)。为了确保这个目的和一些其它的关于测试代码的重要性质,我们有一份描述测试代码书写规范的共享文件。这些原则在代码审阅时被严格执行。

和代码审阅类似,我们对于不同种类的改动有不同的测试标准。如果新改动有可能带来严重后果和修复成本的话,我们会要求更高的代码覆盖率。

所有的这些加在一起,使我们写测试的意义最大化,以此减少长期的开发成本。

代码质量指导

我们非常热衷于共享代码质量指导,这帮助我们:

  • 1. 更好地培训新来的开发者;
  • 2. 更好地在整个团队里共享我们的经验和智慧;
  • 3. 设立共同的标准来提高代码库的一致性;
  • 4. 减少开发和审阅环节的工作量。例如,在每个审阅中都讨论一下每行代码是80个还是100个字符是没意义的。我们可以就讨论这个问题一次,然后在所有今后的代码中都使用这个标准。

除了每种语言自身的语句规范之外,我们也有更抽象的一些代码规范,例如关于如何写出好的测试或是如何架构代码模块,来帮助减少代码的阅读时间。这些规范并不是一成不变的。在我们逐渐对各种权衡有了更深的理解的过程中,我们也会改变这些规范来达到利益最大化。我们也有大型代码重构的工具(部分是诸如例如 codemod 之类的开源工具,其它的是我们自己开发的),以在我们改变了某项规范之后回过头去重构所有的旧代码。

整顿旧代码

一个快速前进的团队会尝试很多新事物,自然而然,它们之中某些很好,而某些则不尽如人意。因此,一个快速前进的公司的代码库里肯定会有很多沉淀下来的糟粕,即那些实际上大家不再使用,却留在那里使许多事情变得更复杂的代码。清楚这些糟粕,保持代码库的简洁,也会提高开发速度。

我们定期组织“整顿周(Cleanup weeks)”来清除这些糟粕。在这些整顿周里,一些指定团队——有时也会是整个公司——把所有的时间都花在清楚那些不用的旧代码上。这些定期活动减少了大家在“常规工作”和“整顿工作”中切换所需花费的时间和精力,也让整顿旧代码变得更为有趣,带来更多的社交价值。

部分代码比其它的更加容易整顿,当然也有部分代码,整顿起来会对开发速度有极大的影响。为了最好地利用大家整顿旧代码的时间,我们会基于清除它们所需耗费的时间,和清除后它们对开发速度带来的影响,对各个代码模块的整顿优先级进行排序。

代码查错与优化(Linting)

人们很容易低估偶尔不遵循代码语言规范(例如代码注释或每行代码的长度)的后果,但这些后果是会叠加起来的。确实,时时记得并遵循很多规范是很恼人的,特别是规范越来越多的时候。因此,我们并不惊讶,很多开发者并不准备遵循这些规范。

我们开发了一个公司内部代码查错和优化的工具,叫做 qlint,来减少达成这一目标的工作量。Qlint 是基于 flake8 pylint开发的智能小工具,能识别文本结构和抽象语法树(AST)。这个工具让我们未来往里面添加新的代码规则变得很容易。例如,我们规定在Python里所有private的变量都必须在变量名前加下划线,因而我们在 qlint 里加了这一条规则来查找所有不符合这一规范的代码。

我们把 qlint 整合进了许多其它开发工具,因此开发者们不必特别来关注 qlint 指出的各项问题。对于刚刚起步的开发者们,我们把 qlint 整合进了最流行的一些编辑器,例如 Vim、Emacs 和 Sublime,并在开发者违反了代码规范的时候提供可视化的提示。Qlint 也整合在了提交代码的流程里,并在任何人想要提交代码的时候以一种互动化的方式运行。事实上,取决于 commit 具体违反了哪条规则,这个工具甚至可能阻止代码部署。我们也把我们的代码规范文档整合在了这个工具里,因此开发者每违反一条规则,qlint 都会给出一个链接指向文档里的那个规则条目。我们的 Phabricator 也被配置成使用qlint。这样,由于所有的错误都由 qlint 以可视化的方式指出了,代码审阅变得更为简单。

所有这些改进都提高了我们代码库的一致性,并使我们能够以最小的成本提高代码质量。

总结

就像这篇文章中指出的那样,Quora 十分严谨认真地对待代码质量。我们对待这个问题很脚踏实地。我们设计并开发了各种工具、系统和流程,来保持并增强我们长期的开发效率。在我们此时达到良好平衡的同时,我们的团队也在不断地扩大和成长,因此我们自信地认为,未来还将开发出更多地工具和系统。

如果你想要帮我们来开发这些工具,或者只是想成为这个超级棒的,认真而脚踏实地地对待代码质量的团队中的一员,请加入我们吧

1 收藏 评论

关于作者:夏殇是只温柔的鮟鱇鹅

简介还没来得及写 :) 个人主页 · 我的文章 · 10 ·  

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部