Facebook 工程师是如何高效工作的？

本篇文章5757字，读完约14分钟

编者按:facebook工程师在高效工作方面有哪些经验？软件工程师采访了一些facebook的高产工程师，总结了他们的共同经验和推广路径，供大家参考。

你可以通过经验、书籍或反复试验来学习成为一名高效的开发人员。但是成为高效开发人员最有效的方法之一是直接从中学习。我采访了几名facebook最有效率的工程师，以了解这些开发人员的基础设施是什么，以实现最高的效率。

第一级:减少不必要的干扰

这似乎是显而易见的，但正是这些积累的小东西最能影响我们的生产力。

避免会议

我尽量少开会。我通常不参加常规会议。这可能不适合每个人，因为经理喜欢安排常规会议，你也不想惹恼经理，但我建议给他看会议成本:(10个工程师x30分钟)/周+10分钟。任务转换费用=浪费工程师半天/周，这不是小数。我总是试图用讨论取代常规会议，或者用话题取代常务会议

-匿名

许多工程师强调会议在必要时是有用的。然而，我们必须以批判的眼光看待会议，不要举行不必要的会议。

为小任务做准备

当生成或修改时，我会快速清理邮箱并将收件箱保持在0？michael novati

有时，在您完成手头的任务后到会议召开前，会有5到15分钟的时间间隔，或者您的试运行可能需要1、5或15分钟。对此，通常的反应是“这次没什么大不了的。”这种说法当然是正确的。许多任务可能需要30分钟到1小时来集中注意力，但不是所有的任务都能做到。许多工程师提到他们会列出一个小任务清单，这样他们就可以在每天的一点空闲时间里处理掉这些事情。例如，邮件处理、差异(见注释)审查、回复内部帖子，甚至小规模的差异/重构，从而提高一天的生产率。

戴上降噪耳机

如果你曾经在一家不久前成立的软件公司工作过，你会注意到那里的办公环境是空.这对工程师来说是一把双刃剑。一方面，你可以更接近团队。团队成员之间的协作和友谊可以一直保持较高的水平，方便提问，与同事的关系也可以很融洽。糟糕的是，你宝贵的注意力被环境噪音干扰了。当你在思考困难的问题时，大声的讨论会影响你的生产力。此时，降噪耳机可以派上用场。这种耳机的技术已经非常先进，远远超过了在你的耳朵里竖起一个障碍，把耳机的音量调大。真正的噪音消除耳机可以消除环境噪音，抑制周围的低交谈。在和迈克尔·诺瓦蒂交谈后，我还买了一副他推荐的耳机。老实说，没有它我无法工作。显然，戴上这样一副耳机作为比较，你就会知道办公室环境有多嘈杂。

在别人不能干涉你的时候工作

(关于如何处理干扰)两年前搬到纽约可能对我有很大帮助

—亚当·恩斯特

我通常把更困难和复杂的任务留到星期三(那时我可以在家不受干扰地工作)

鲍勃·鲍德温

事实上，在“正常”的工作时间我什么也做不了，只有加班才能完成事情。

-匿名

我通常可以在早上6: 00到9: 00之间做比一天中其他时间更多的事情。长时间保持不间断是非常重要的

-匿名

我必须承认，与这些工程师交谈的最大发现之一是，他们中的许多人工作时间很长。他们为什么要工作这么久？原因很有趣。因为只有在早上，深夜，周末，没有人打扰他们。通过寻找一天中最少的中断时间，这些人可以推进他们的主要任务，并得到代码。

减少恼人的电子邮件/通知

我会关闭所有非紧急邮件提醒。只接受需要行动的电子邮件，强迫自己以合理的频率查看任务/电子邮件页面。它实际上帮助我将其他东西视为垃圾邮件，但我错过的东西更少。

——？ari chivukula

如果你每次收到新邮件都要停下来检查，你会被各种各样的干扰打断一整天。通过减少和过滤通知，只保留必要的通知，您可以在没有干扰的情况下工作更长时间。

不要失去你的状态

当我被打断(或者不得不洗澡)时，我会在脑海中“保存我的状态”，就像在gameboy模拟器中保存我的状态一样，这样当我回去继续的时候就可以尽快恢复。

——？michael novati

总是在一个相当简单或机械的任务中结束一天。这让你很容易在第二天捡起来，而不是从头开始。

—亚当·恩斯特

对我来说，当我认真思考的时候，当我被打断的时候，当我忘记我在想什么的时候，我会在编程中失去我的状态，这意味着我需要再次重复整个思考过程。

工作时遇到干扰的最好方法之一就是延迟干扰。如果你在集中注意力的时候分心了，告诉那个人你以后会处理它，做一个速记，然后继续工作，直到你到达一个合理的停止点。一旦你到达停止点，你应该立即处理积累的东西。

如果干涉不能推迟，有许多方法可以“保持状态”。例如，写下你当前的思考过程，写下失败测试，或者简化你正在思考的问题。

第二层:写“更好”的区别

好的代码意味着很多事情。好的代码应该是功能性的，易于审查，经得起时间的考验，等等。

写一个较小的差异

许多小差异就像解决工程问题时“展示你的工作”

-匿名

我采访的每个工程师都强调将代码变更分成逻辑模块，这可以让其他人更容易理解它们，更快接受它们。通过减少由差异引起的认知负荷，评审者将更有信心接受变化。此外，通过减小diff的规模，这种变化对评审者来说并不那么令人生畏，因此评审效率会更高。

我可以告诉你，这篇文章中询问的工程师是在过去六个月里在facebook上提交最多不同意见的人。工程师可能有两种风格，一种是提交许多小规模的差异，另一种是提交少量大规模的差异。

堆叠差异和多任务处理

大多数工程师提到，他们会将不同的变更堆叠在一起，并逐渐建立不同之间的逻辑依赖关系:

有时候，当我做一个大规模的比较时，我会回去把它分成一系列逻辑步骤，这样我就可以慢慢地改变一些东西，然后代码的整体质量就会逐渐提高

-匿名

我从不堆叠差异。相反，我并行地做几件独立的事情，然后在等待审查的时候交替处理它们。将一个大的变化分解成独立的部分也是有效的，例如添加接口，添加结束节点，以及将这些事情插入到待办事项列表中……这样事情就可以交替地堆积和完成，并且不需要在不同的部分之间有严重的依赖性。结构化代码使审查、交付和恢复变得更加容易，而无需堆叠或分支。

—michael novati

如果我觉得我把多个DIFF放在一个DIFF中，我会把它取出来放在堆栈上，形成一个相互依赖的关系。

-匿名

要小，或者至少容易判断。这不仅是为了更容易和更快的审计，也是为了我能写更好的代码，因为我认为如果每次处理都是合乎逻辑的，那么浪费的调试时间将非常少。此外，堆叠diff的经验可以使小diff易于管理。

ari chivukula

我广泛使用堆栈差异。除了这样做，我还可以在等待代码审查的时候做些事情。将代码分解成更小的差异常常允许我从宏观的角度考虑我在做什么，甚至简化架构。

-匿名

无论工程师使用堆叠式diff还是多任务diff，他们的工作效率似乎都很高，这表明这两种方法在提高效率方面都是有效的。

单元测试

考试的规模应该尽可能小，这样我会感觉更舒服。

—michael novati

每个人都更容易接受单元测试的代码。

-匿名

在一些技术公司，单元测试是有争议的，大多数团队和公司对工程师是否应该写测试有自己的指导。但是有一点是肯定的，如果你公司的其他人可以修改你的代码，确保没有人破坏你的代码的最好方法是在测试中强制执行功能需求。

沟通

对于困难的差异，我将适当地添加几个审阅者，并在适当的组中共享差异。不管有没有行动，我每天都会有所不同。如果几天没有行动，我会问评委他们对diff有什么惊人的发现，然后对结构进行修改。最后，我会尽可能多的和对方交流。我总是从“[产品/标签]”开始，这样每个人都可以知道diff的功能。如果我想尽快被接受，我会写一些类似“[产品-尽快]”或“[产品-推锁]”的东西。

——？michael novati

这似乎是显而易见的，但是有很多方法可以交流关于diff review的信息。一般的经验法则是根据差异进行。如果审阅您的diff的人通常不与您打交道，您可能需要在描述和标题中添加一些上下文信息，这是您与团队成员交流时不需要的。如果相关的逻辑比较复杂，你也可以在需要别人检查的地方发表意见。

在设计会议上提出期望也可以简化编写代码的过程，开发好的api和架构。

不要害怕提醒评委你的不同。如果他们不想检查你的差异，他们可以退出或者建议其他人去做。如果diff让队列一直被检查，这就等于把冲突埋在未来。

第三级:团队精神

编码是一项团队运动，就像所有的团队运动一样，一个人能取得的成就总是有限的。

查看其他人的代码

快速扫描、通读、修补、测试和评论

-匿名

为了改进代码输出而进行更多的审查听起来有点矛盾。我们可以把“做更多评论”理解为“清理别人的队列”。当你从不同的角度看问题时，情况就清楚多了。如果你清除了其他工程师的队列，那么其他工程师更有可能帮助你清除你的队列并为你解锁。

与审阅者/团队成员建立信任

我有一个核心工程师团队，他们与内部人员保持着良好的信任关系。我们将一起工作，快速检查彼此的代码。

-匿名

这一点与前一点有些相似。如果你有一个核心的工程师团队，他们可以互相信任来编写好的代码，你可以相对安全地进行修改，因为即使一个工程师写错了什么，当出了问题时，每个人都会一起工作来纠正它。

对你正在做的事情保持透明

在开发新项目时，应该使用征求意见。与以后改变方向相比，提前获得/header/建议api反馈是值得的。

——？adam ernst

如果人们不知道你在做什么，他们会很困惑，因为没有足够的信息来查看diff。通过尽早让评审员/团队成员进入这个圈子，他们可以在大量工作完成之前提供反馈，并且前进道路上的路障将被清除。

提供良好的反馈

专注于提供高质量的反馈，而不是寻找错误。如果你发现了一个错误，指出来，但是相信工程师已经测试过了(并且相信他们会纠正任何发现的错误)

鲍勃·鲍德温

略读首先要了解大致情况，如果有什么不清楚的地方，就评论一下或者提出改进的建议。如果整体感觉良好，请仔细阅读，看看是否有任何最佳实践问题或次要细节。如果没有，请留下一些评论来接受更改。

——？ari chivukula

对“评估差异的策略是什么？”这个问题的普遍回答是是从高层次的角度理解要评估的差异。在理解了diff的基本结构之后，我们可以进一步理解代码风格并检查逻辑。

请求更改

经常使用请求变更——最糟糕的是他们重新请求审查(当然，如果作者认为你的请求变更是错误的，鼓励他们这样做)

——？adam ernst

如果我能看到自己的问题，我会要求进行单元测试或重构，这样问题出现的可能性就会更低。如果事情太大太复杂，显然没有人注意，请他们完成评估，或者至少为将来更好的实践提出建议。

-匿名

在一些非标准的事情上要求不同的改变可能有点尴尬。然而，从长远来看，鼓励更好的编码实践和校准是值得的，工程师将从错误中学习，并因做出改进而获得回报。

我不知道。承认吧

如果我不确定代码库的一部分，我就直接说出来，跳过它。

——？michael novati

假装你不知道如何理解不会花很长时间。如果你不知道复习什么，坦率地告诉别人，然后让他们去找其他更了解复习的工程师。

第4级:组织和晋升

待办事项列表

我会把我的个人事务放在我的日程表上，并提醒自己以后要做。如果日程表上没有提醒，我会忘记的。

——？michael novati

大多数时候，我询问的每个工程师都会使用不同的任务跟踪工具。同时，要跟踪和管理的资源包括纸张、任务、邮件、时间表、列表和高级目标。然而，许多工程师在决定下一步做什么以及组织和分类任务和邮件时有一个“分级”机制。

快速失败和迭代

我会尽快调整代码，即使我不确定这是最好的解决方案。我宁愿很快失败，也不愿100%地先考虑它。

ari chivukula

代码不会吓到我，我可以轻松进入状态？，出拳有反抗的手段

——？michael novati

许多工程师(包括我自己)可能隐藏的一件事是对失败的恐惧。很快制造出完美产品的想法是可怕的，这将导致我们思考太多的问题。养成在不知道结果的情况下立即编写代码的习惯，这样我们可以更快地迭代，更快地看到结果。

工作/生活平衡

有人比你更努力工作是有帮助的，否则你将不得不自己承担。我的做法是放松。有时我冲刺一会儿，然后放松。就像高强度运动持续两个月，然后放松一个月。在我看来，这比保持三个月相同的节奏更有效(尽管这并不适合每个人)，因为工作不是线性的。

-匿名

“洗澡时思考”的比喻有些道理

——？adam ernst

这些工程师工作非常努力。他们花了大量时间来完成大量代码。虽然我没有特别询问工作/生活的平衡，但他们中的许多人都清楚地区分了工作和生活，甚至是那些“全力以赴”的工程师，这让我很惊讶。似乎这些人不仅能有效地工作，而且能很好地平衡工作和生活——如果他们想的话。

零散的想法

你应该像你希望别人对待你那样对待别人。你必须是那种其他人想与之共事的工程师，这大部分是通过反馈学到的。尽早并经常询问。被询问的人会感到被重视。

——？ari chivukula

经过这些面试，我觉得我的发展过程正在一点一点地演变(同事们必须努力工作来引起我的注意，因为我现在戴着噪音耳机)。拆分差异、请求审查、待办事项列表，这些我以前都做过，但现在我知道如何更有效地使用这些工具。说实话，采取上述措施后，我的效率提高了很多。

注意:

1.diff:所谓的diff:facebook工程师指的是由开源工具phaser创建的differentialrevision。这些修订是放入phabricator中供其他工程师审查的代码更改。工程师可以评论、请求修改或接受代码修改，然后将它们转移到产品中去影响实际用户。facebook编写的每一个代码都要经过这个验证步骤，以确保工程师之间的持续协作和相互反馈。

2.堆叠的区分:指区分的堆叠。上差分格式的逻辑依赖于下差分格式，其功能是基于所有下差分格式的功能开发的。这使得工程师能够在简单和小规模的变更的基础上开发功能，便于审查，并逐步实现更大的目标。

如果转载，请注明出处

“读完这篇文章还不够吗？如果你也开始创业，希望你的项目被报道，请点击这里告诉我们！”