GitHub如何运作(二) —— 异步工作

导读：GitHub公司的职员Zach Holman写了一篇关于“GitHub如何运作管理”的文章，文章分三部分，这是第二部分：异步工作。

        这是目前为止我在GitHub工作最喜欢的方面：每件事都是异步的。

        聊天

        GitHub在最初的两年没有办公室。我们用聊天室(Campfire)来沟通。现在我们已经搬到了第二个办公室，但仍然使用Campfire。这是因为聊天可以是不同步的。

        用这种异步的交流方式，我可以出去吃饭，然后当我回来的时候我仍能跟得上对话；我可以问同事一个问题，不用担心会打扰到她，因为当她有时间的时候她自然会回复；我可以去Minnesota的乡村，也可以同平时一样好像在办公室工作。

        Pull Requests

        （编注：“Pull Requests”是GitHub上的一种讨论形式，有关代码讨论、代码审查、管理代码的变化。Pull Requests = 代码 + 问题 + 代码注释）

        我们的开发工作流程中涉及Pull Requests，我想在以后的博客中更加详细的讲述这一流程。现在我只想表达我对这种方式的喜爱之情。以前那些需要进行复杂的分支操作的日子一去不复返了，取而代之的是只需要自己对着屏幕查阅代码的简介方式。

        如果我想增加一个新功能，或者会修改代码，我会将代码push到一个新分支，并且新建一个Pull Requests。如果我的代码会影响我同事的代码，或者他们对我的代码感兴趣，或者他们时间充裕的话，他们可以查看我的代码。这时我们可以将那个分支发布到其他机器上，调试新功能，如果一切正常的话，就可以将这个分支合并到主分支去。

        有了Pull Requests的工作方式，我就不需要特别去开个会，方便了每个人。

        还有个原因：开会是有害的

        37signals在《Getting Real》一书中讨论过“开会是有害”的这个主题。相对于37signals，我对于开会的厌恶是有过之而无不及，我讨厌开会。

        往往你正在忙的时候，就要开会了。他们还经常会请一些不相关的人开会。即使你对回忆的主题很感兴趣，你也会最终被搞得懊恼。因为开会，你不得不停止后头的工作，而开会却是跟你“谈论”你正在做的工作。开会期望你提前在白纸上设计出完美的系统，而显然push一个分支，查看diff，基于diff来修改代码更简单些。

        除此之外，开会的内容很容易被遗忘。即使你做了会议记录，你也不能保证你能记录所有内容。有某些你没有来得及记下来，你想会后再补上记录。的那是三个星期过去了，你回忆起好像某些东西没有记录下来，显然那次讨论才是更重要的。如果采用聊天记录的方式，就不存在这个问题。另外文字沟通的方式也减少了开会时开小差的情况。

        我们在GitHub也会开会，但是过去的一年半中开会的次数屈指可数。

        最佳状态

        再回到我的上一篇文章：你想要你的雇员处于“最佳状态”。但是如果他们只能在那种状态下工作一个小时就要开会了，这将打乱他们。

        我们发现，如果让那些负责任的人按照他们自己的时间来安排工作，他们不仅能完成重要的工作，也能保证其他工作的高效率。