GitHub如何運作：異步工作

導讀：Github 公司的職員 Zach Holman 寫了一篇關于“GitHub 如何運作管理”的文章，文章分三部分，這是第二部分：異步工作。（下面是全文）

這是到目前為止我在 GitHub 工作最喜歡的方面：每件事都是異步的。

聊天

GiHtub 在最初的兩年沒有辦公室。我們用聊天室(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 也會開會，但是過去的一年半中開會的次數屈指可數。

最佳狀態

再回到我的上一篇文章：你想要你的雇員處于“最佳狀態”。但是如果他們只能在那種狀態下工作一個小時就要開會了，這將打亂他們。

我們發現，如果讓那些負責任的人按照他們自己的時間來安排工作，他們不僅能完成重要的工作，也能保證其他工作的高效率。

英文原文：How GitHub Works: Be Asynchronous
      來自: blog.jobbole.com