Be asynchronous - 异步[1]工作 Back
- 原文链接 : How GitHub Works: Be Asynchronous
- 原文作者 : Zach Holman
- 译者 : aleen42
- 校对者 : 暂无
- 状态 : 待校对
你正在阅读的是 Github 如何工作系列的第二部分。该系列总共有三篇文章，并带你走进 GitHub 的世界当中。这些文章全是针对不同的话题而相互独立的，如果你有兴趣的话，你也可以阅读其他的两篇文章：时间就是粪土与创新是非常重要的
在 GitHub 所提倡的工作观念中，有一点是我目前尤其欣赏的。那就是，所有的一切都需要处于异步工作状态。
聊天
由于 GitHub 在头两年并没有一个正式的办公室，因此，聊天室（在我们这称作，营火会（Campfire））是我们完成所有事情的地方。如今，虽然我们搬到了第二个办公室，但营火会仍然是我们把事情完成的地方。这其中是有缘故的：因为在那里，我们可以能异步地进行聊天。
当沟通是处于异步工作状态时，这就意味着我随时可以去吃我的午饭，而不影响到某一个沟通过程。因为在午饭回来后，我只需要通过聊天记录，就能重新进入这个沟通过程之中。此外，这还意味着我能随时向我的同事询问问题，而不需要担心干扰到他的工作。因为当他有空的时候，他就会返回到我们的沟通之中。最后，异步式沟通也意味着，当你处于在那看似乡村的明尼苏达州，也仍能感受到像平常一样在办公室中工作的气氛。
拉取请求[2]（Pull Requests）
我们开发工作主体中就涉及到该名词，拉取请求。关于这个名词的概念，我会在未来的博文中进行详细的探讨，但同时请允许我说一句，“生活在一个充满“拉取请求”的世界中是一种何等雄伟的体验。”换句话说，我在公司的日子是伴随着复杂的分支策略，以及个人的代码复查所流逝的。”
假设我希望往代码库中添加一个新的功能或者产生一点改变，那么我需要推送一个新的分支，并为该分支创建一个拉取请求。然后，我的同事就会审视该请求：1）该请求对他们的代码是否产生了改变；2）他们是否感兴趣于该次请求所涉及的问题；3）或者当他们有充足的时间时，会去核对我所提交的请求中所产生的变动。审视过后，我们会在不同的机器子集中运行该部分的代码，并在生产环境中尝试各种的测试用例。当所有的测试都通过时，该请求就会被合并到主分支 master [3]上。
有了拉取请求，我就不需要去拉拽任何人去开会，而且这对于他们和我来说都是一种很不方便的做法。当然，下面我也会说说为什么这是很不方便的做法：
会议犹如毒品
“37 signals” 组织在栏目 “Getting Real” 上对是否应该开会的问题，曾写过一篇文章，名为 “会议犹如毒品”。个人而言，我对于会议的厌恶程度并不亚于 37 signals 组织。确切来说，我对“会议”一词是很鄙视的。
一般，会议是当你需要仔细讨论解决方案时才会召集的。但往往我们会邀请比实际所需更多的人来参加此次会议。即使多出来的这些人对会议的话题是感兴趣的，但他们仍然会对此感到愤怒。因为，会议把他们从一个正在工作的状态拉到了一个跟大家讨论工作情况的状态。在我看来，这种问题是可以通过简单地方式来解决的。那就是查看我们所推送分支的代码，比较差异部分，然后就能看出我们的工作进展。而不是仅仅通过我们的汇报，就假定我们能按时完美地完成，如“白板系统”的设计。
除此之外，会议的内容很容易会被员工彻底地遗忘。即使在会议上，你记录了会议的内容，但你也并不能捕获到所有的会议内容。当忙不过来时，你就会决定在往后再记录之前所说的内容。可你会发现，三周后当你尝试去填充空白的那段会议内容时，你的记忆早已变成空白。相反，如果通过聊天记录，你就不会担心诸如此类问题的出现。再且，异步式聊天能对员工讨论的方式产生潜移默化的改变，使得他们能用精炼的语句来提高讨论的质量，并减少冗长散漫的思考。
当然，在 GitHub 里，我们也会有会议，但所开的会议可谓寥寥可数。在过去的一年，我们仅开过大概5次的会议。
正确的思维区域
关于该正确区域，我们可以回顾一下昨天我所写的一篇文章：“你渴望你的员工能处于“该正确的思维区域””。如果我们把员工置于一种在团队会议前仅有一个小时工作时间的状况时，那么，该员工还能处于那所谓的“思维区域”吗？明显是不可能的。
所以，我们会发现，如果能让责任心强的员工按照自己的时间去处理自己的工作，那么，最终他们不仅会把重要的事情完成，而且还能在其他的工作上富有硕果。
注解
[1]：所谓异步，在计算机领域中指的是线程间的执行顺序，线程指的是程序中的一个代码片段。异步的概念是相比同步而言，两线程异步指的是一个线程并不需要理会另一个线程的工作。
[2]：所谓拉取请求，是 GitHub 公司提出的一种概念。目前，大部分项目的开发都有一个叫“分支”的概念。这概念主要用于项目的协同开发，即多个人同时开发同一个项目。若有协同开发的时候，项目开发者就会为自己创建一条独立的分支进行开发，而其他开发者的分支并不会影响到自身的分支。当开发完成时，开发者需要把自己开发的部分叠加于原有的项目上，那么此时就需要提出所谓的“拉取请求”，顾名思义就是请求项目负责人拉取自己的分支代码，并合并到项目里。
[3]：master 分支，指的是一般项目的主体代码部分。一般，在该分支上的代码都是处于经过测试后所发行的版本。