GitHub如何运作：异步工作
jopen 13年前
<p> 导读：Github 公司的职员 Zach Holman 写了一篇关于“GitHub 如何运作管理”的文章，文章分三部分，这是第二部分：<strong>异步工作</strong>。（下面是全文）</p> <p> 这是到目前为止我在 GitHub 工作最喜欢的方面：每件事都是异步的。</p> <p> <strong>聊天</strong></p> <p> GiHtub 在最初的两年没有办公室。我们用聊天室(Campfire)来沟通。现在我们已经搬到了第二个办公室，但仍然使用 Campfire。这是因为聊天可以是不同步的。</p> <p> 用这种异步的交流方式，我可以出去吃饭，然后当我回来的时候我仍能跟得上对话；我可以问同事一个问题，不用担心会打扰到她，因为当她有时间的时候她自然会回复；我可以去 Minnesota 的乡村，也可以同平常一样好像在办公室工作。</p> <p> <strong>Pull Requests</strong></p> <p> （编注：“Pull Requests”是 GitHub 上的一种讨论形式，有关代码讨论、代码审查、管理代码的变化。 Pull Requests = 代码 + 问题 + 代码注释。）</p> <p> 我们的开发工作流程中涉及 Pull Requests，我想在以后的博客中更加详细的讲述这一流程。现在我只想表达我对这种方式的喜爱之情。以前那些需要进行复杂的分支操作的日子一去不复返了，取而代之的是只需要自己对着屏幕查阅代码的简洁方式。</p> <p> 如果我想增加一个新功能，或者会修改代码，我会将代码 push 到一个新分支，并且新建一个 Pull Requests。如果我的代码会影响我同事的代码，或者他们对我的代码感兴趣，或者他们时间充裕的话，他们可以查看我的代码。这时我们可以将那个分支发布到其他机器上，调试新功能，如果一切正常的话，就可以将这个分支合并到主分支去。</p> <p> 有了 Pull Requests 的工作方式，我就不需要特别去开个会，方便了每个人。还有个原因：</p> <p> <strong>开会是有害的</strong></p> <p> 37signals 在《Getting Real》一书中讨论过“开会是有害的”这个主题。相对于37signals，我对于开会的厌恶是有过之而无不及，我讨厌开会。</p> <p> 往往你正在忙的时候，就要开会了。他们还经常会请一些不相关的人开会。即使你对会议的主题很感兴趣，你也会最终被搞得懊恼。因为开会，你不得不停止手头的工作，而开会却是跟你“谈论”你正在的工作。开会期望你提前在白纸上设计出完美的系统，而显然 push 一个分支，查看 diff，基于 diff 来修改代码更简单些。</p> <p> 除此之外，开会的内容很容易被遗忘。即使你做了会议记录，你也不能保证你能记录所有内容。有某些你没有来得及记下来，你想会后再补上记录。但是三个星期过去了，你回忆起好像某些东西没有记录下来，显然那次讨论才是更重要的。如果采用聊天记录的方式，就不存在这个问题。另外文字沟通的方式也减少了开会时开小差的情况。</p> <p> 我们在 GitHub 也会开会，但是过去的一年半中开会的次数屈指可数。</p> <p> <strong>最佳状态</strong></p> <p> 再回到<a title="GitHub 如何运作：时间并不决定一切" href="/misc/goto?guid=4958200101262182756" target="_blank">我的上一篇文章</a>：你想要你的雇员处于“最佳状态”。但是如果他们只能在那种状态下工作一个小时就要开会了，这将打乱他们。</p> <p> 我们发现，如果让那些负责任的人按照他们自己的时间来安排工作，他们不仅能完成重要的工作，也能保证其他工作的高效率。</p> <p> 英文原文：<a href="/misc/goto?guid=4958200102008032987">How GitHub Works: Be Asynchronous</a><br /> 来自: <a id="link_source2" href="http://blog.jobbole.com/6815/?utm_source=rss&utm_medium=rss&utm_campaign=github%25e5%25a6%2582%25e4%25bd%2595%25e8%25bf%2590%25e4%25bd%259c%25ef%25bc%259a%25e5%25bc%2582%25e6%25ad%25a5%25e5%25b7%25a5%25e4%25bd%259c" target="_blank">blog.jobbole.com</a></p>