成為高效開發者這件事你可以通過經驗、書本、或者試驗和錯誤來學習。但成為高效開發者的最有效方式之一是直接向高效開發者學習。我訪談了 Facebook 的幾位最高產的工程師，想找到這些開發者實現最高生產力的基礎結構是什么。

第一級：減少不必要的干擾

這一點似乎很明顯，但是正是這些累積起來的小事情最影響我們的生產力。

避免開會

我盡量少開會。例會我一般都不參加。這條未必適合每一個人，因為經理喜歡安排例會，你也不想把經理給惹毛了，但我建議給他看看開會的成本：（10 工程師 x30 分鐘）/ 周 +10 分鐘任務切換開支=浪費工程師半天時間 / 周，這可不是小數。我總是努力爭取用有議題的討論或者站立會議來代替例會

—匿名

許多工程師都強調必要的時候會議是有用的。但是必須對開會保持批評性的眼光，不開不必要的會。

準備好做小任務

在生成或者修訂的時候我會迅速清理郵箱保持收件箱為 0—?Michael Novati

有時候在你完成手頭任務之后到開會之前會有 5 到 15 分鐘的間隔，或者你進行的試運行可能需要花費 1、5 或 15 分鐘的時間。對此通常的反應是 “這種時間里面做不了什么大事的。” 這種說法當然沒錯，許多任務可能都要花 30 分鐘到 1 小時的時間才能集中注意力，但并不是所有任務都這樣。許多工程師提到自己會做一份小任務清單，這樣在每天稍微閑暇的時間里就能把那些事情處理掉。比如處理郵件、diff（參見附注）評審，回復內部帖子，或甚至可以進行小規模的 diff/ 重構，從而提高一天的工作效率。

戴上噪音消除耳機

如果你在成立時間不久的軟件公司呆過，你就會注意到那里的辦公區域設置是如何的空曠。對于工程師來說這是一把雙刃劍。一方面你跟團隊的距離可以更加靠近。團隊成員間的協作和友情可以一直保持很高水平，問問題很方便，跟同事關系也可以很融洽。不好的是你寶貴的專注度被環境噪音干擾了。當你正在思考棘手問題的時候，聲音很大的討論會贏影響到你的生產力。這時候噪音消除耳機就可以派上用場了。這種耳機的技術已經非常先進了，遠不止是在你的耳邊豎起一道屏障，調大耳機音量。真正的噪音消除耳機能夠排除環境噪音并且抑制周邊低沉的交談聲。跟 Michael Novati 談過以后我也買了一副他推薦的耳機，說實話要沒了它我都沒法干活了。很顯然，戴上這樣一副耳機進行對比之后，你就會知道辦公室的環境噪音有多大。

在別人沒法干擾你的時候工作

（關于如何應對干擾）2年 前搬到紐約去可能對我的幫助很大

—Adam Ernst

我通常把更困難更復雜的任務留到星期三（那時候我可以在家工作不受干擾）

—Bob Baldwin

實際上 “正常” 工作時間內我干不了什么事情，只有靠加班時間才能完成事情

—匿名

我通常在早上 6 點到 9 點間能夠干的事情比一天其他時間能干的都要多，長時間的不受打斷至關重要

—匿名

我得承認，跟這幫工程師聊的最大發現之一是他們當中許多都工作很長的時間。為什么他們要干那么久呢？原因挺有趣的。因為只有在早上、深夜、周末這些時間才沒人打擾他們。通過尋找一天當中受打斷最小的時間，這些人得以推進自己的重大任務，把代碼給弄出來。

減少煩人的郵件 / 通知

我會關閉所有非緊急的郵件提醒。只接受需要行動的郵件，并且強迫自己按照合理的頻率來檢查任務 / 郵件頁，把其他東西當成垃圾郵件實際上對我是有幫助的，我錯過的東西反而更少了。

—?Ari Chivukula

每次收到新郵件時都要停下來去看看的話，你一整天都會被各種干擾打斷了。通過減少和過濾通知到只保留必要的那些，你就能在不受干擾的情況下工作更久。

不要失去狀態

我被打斷（或者必須去洗澡）的時候會在腦中 “保存狀態”，就像在 Gameboy 模擬器中保存狀態一樣，這樣回頭繼續的時候我就可以盡快恢復了。

—?Michael Novati

永遠要在一項相當簡單或機械的任務中結束一天。這讓你第二天很容易就可以撿回來恢復工作狀態，而不是又要從頭開始。

—Adam Ernst

對于我來說，當我在認真思考問題時、被打斷時、忘記自己在想什么時就會在編程方面會失去狀態，也就意味著我需要重新把整個思考過程再過一遍。

當你在工作狀態時遇到干擾最好的辦法之一是推遲干擾。如果你在全神貫注的時候被干擾，那就告訴那個人你稍后會處理，速記一下此事，然后繼續工作直到你到達合理的停止點。一旦到達停止點，馬上處理完堆積的那些事情。

如果干擾無法推遲，也有很多辦法可以 “保持狀態”。比如寫下自己當前的思考過程，寫下失敗測試，或者簡化正在思考的問題。

第二級：寫出 “更好” 的 Diff

好代碼意味著很多東西。好代碼應該是功能性的，容易評審的，經得起時間考驗的，等等。

寫更小的 Diff

許多小的 diff 就像是在解決工程問題時 “展示你的工作”

—匿名

我訪談的每一位工程師都非常強調把代碼變更拆分為邏輯模塊，這樣可以讓其他人更容易理解，更快接受。通過減少 diff 帶來的認知負荷，評審者對于接受變更會更有信心。此外，通過減少 diff 的規模，變更對于評審者來說也沒那么令人望而生畏，這樣評審效率也會更高。

可以告訴你們的是，這篇文章問到的工程師都是過去 6 個月Facebook 里面提交 diff 最多的人。可能會有兩種風格的工程師群體，一群是提交很多小的 diff 的，一群是提交數量較少但規模較大的 diff。

堆疊 diff 以及多任務處理

大多數工程師提到自己會將 diff 變更相互堆疊起來，逐步建立 diff 間的邏輯依賴：

有時候當我做了一個規模很大的 diff 時，我會回過頭把它拆分成一系列邏輯步驟，這樣我就能慢慢變更一些東西，然后代碼的總體質量也會逐步得到改善

—匿名

我從來不堆疊 diff，相反，我會并行做幾樣獨立的事情，然后在等待評審的時候交替處理。把一項大的變更分解成獨立部分這種做法也很有效，比方說增加界面，增加端結點，把這些事情安插進待辦事宜里面……這樣可以把事情堆起來交替做，不用在 diff 之間產生嚴重依賴。對代碼進行結構化，這樣就不必堆疊或者弄子分支出來，評審、交付、還原都容易一些。

—Michael Novati

如果我覺得自己在把多個 diff 放進一個 diff 的話，我會拿出來放到堆棧上形成相互依賴關系。

—匿名

要做小的，至少是容易評審的 diff。這不僅是為了更容易更快地審核，也能讓我寫出更好的代碼，因為我認為如果每次處理的東西邏輯分明的話，浪費的調試時間就非常少了。此外對堆疊 diff 的經驗可以可以讓小的 diff 可管理。

—Ari Chivukula

我大量使用堆疊 diff。這么做除了讓我可以在等待代碼評審時有事可做以外，把代碼分解更更小的 diff 往往能讓我從宏觀上考慮自己在做什么，甚至還能簡化架構。

—匿名

無論工程師是使用堆疊 diff 還是進行 diff 的多任務處理，其生產力似乎都相當出色，這說明這兩種辦法對提高效率都很有效。

單元測試

測試規模要盡可能小，這樣我會感覺舒服一點。

—Michael Novati

大家對經過單元測試的代碼更容易接受些。

—匿名

單元測試這個東西在一些技術公司會引起爭議，大多數團隊和公司對于工程師要不要寫測試都有自己的指導意見。不過有一件事可以肯定，如果你所在的公司別人可以修改你寫的代碼的話，確保某人不會搞砸你的代碼的最好辦法是在測試中強制功能要求。

溝通

對于比較棘手的 diff，我會適當增加幾個評審人，把 diff 共享到合適的群里面。不管有沒有動作，我每天都會 ping 一個 diff 出來。如果好幾天都沒有動作，我會問評審的對 diff 有什么驚人的發現，然后對結構做出改變。最后我會盡可能跟對方多溝通。我總是以 “［產品 / 標簽］” 作為標題開頭—這樣大家就能知道 diff 是做什么的，如果我想盡快得到接受，我會寫上 “［product-ASAP］” 或者 “［product-PUSHBLOCKER］” 之類的東西。

—?Michael Novati

這一點似乎顯而易見，但是就 diff 評審進行溝通的方式有很多種。一般的經驗法則是按 diff 來進行。如果審核你的 diff 的人平時不怎么跟你打交道的話，你可能要在描述和標題上面增加一些平時跟團隊成員溝通時不需要的上下文信息。你還可以在需要別人重點審查的地方做批注，如果相關邏輯比較復雜的話。

在設計會議上就提出期望還可以簡化寫代碼的過程，開發出好的 API 和架構等。

不要害怕提醒評審者注意你的 diff。如果他們不想審核你的 diff，他們可以退出或者建議其他人來做。如果讓 diff 一直留著待審查隊列，那無異于給將來埋下沖突。

第三級：具備團隊精神

編碼是一項團隊運動，就像所有的團隊運動一樣，個人能實現的事情總是有限的。

評審他人的代碼

快速掃描，通讀，打補丁，測試，評論

—匿名

多進行評審以便提高你的代碼產量，這句話聽起來似乎有點矛盾。我們可以把 “多做評審” 解讀為 “清理別人的隊列”。當你換個角度看問題時，情況就清楚多了，如果你清理了其他工程師的隊列，那別的工程師也就更有可能幫你清理掉你的隊列，替你解鎖。

與評審者 / 團隊成員建立信任

我有一個核心工程師小組，跟里面的人維系著良好的信任關系，我們會一起努力迅速評審對方的代碼。

—匿名

這一點跟上一點有點類似。如果你有一組核心的工程師，相互能夠信任對方能寫出好代碼的話，你就可以相對安全地做出變更，因為哪怕某位工程師寫錯了東西，大家也會在出現問題時一起努力改好它。

對自己在做什么要透明

進行新項目（greenfield development）開發時應該用 RFC（請求評論）diff。相對于在后面才改變方向，預先獲取 /header/ 提議 API 反饋所消耗的時間是值得的。

—?Adam Ernst

如果大家不知道你在做什么，因為評審 diff 時需要的信息量不足會導致他們困惑。通過盡早把評審者 / 團隊成員納入圈子里面，他們就能在一大塊工作完成前提供反饋，前進道路的路障也就被解除了。

提供好的反饋

專注于提供高質量的反饋而不是挑刺。如果你發現 bug 了就指出來，但是要相信工程師已經測試過（并且相信他們會改正任何發現的 bug）

—Bob Baldwin

先略讀了解概況，如果有什么地方不清楚就批注一下或者提出改進建議。如果總體感覺良好，再細讀看看是否存在最佳實踐問題或者小細節問題，沒有的話留幾條注釋接受變更就行了。

—?Ari Chivukula

“評審 diff 的策略是什么” 這個問題的常見回應是首先從高層視角理解待評審的 diff。在理解了 diff 的基本結構之后，再深入了解代碼風格并進行邏輯檢查。

請求變更

要頻繁使用請求變更—最糟糕的事情莫過于他們重新請求評審（當然要鼓勵作者這么做，如果對方認為你的請求變更是錯誤的話）

—?Adam Ernst

如果我可以看出自己的問題，那就請求單元測試或者重構，這樣出問題的可能性會低一點。如果東西太大太復雜而且顯然沒人把心思放在這上面，那就請求他們結束評審，或者至少給出將來更好做法的建議。

—匿名

在一些非標準事情上對 diff 提出請求變更可能會有點令人尷尬。但是從長遠看，鼓勵采取更好的編碼做法和校驗是值得的，工程師以后會從錯誤中吸取教訓并作出改進中得到回報。

不知道要承認

如果我對代碼庫的一部分不太清楚我會直接說然后跳過。

—?Michael Novati

不懂裝懂是裝不了多久的，如果要評審的東西你不懂就坦白告訴別人，然后讓對方去找別的更懂的工程師評審。

第四級：組織與推進

待辦事宜

我會把日程表里面的個人事務先放到一邊，設置提醒稍后再辦。如果日程安排里面不設提醒我會忘了。

—?Michael Novati

大多數情況下，我問到的工程師每個人都會使用不同的任務跟蹤工具。同時要跟蹤管理的來源還包括紙、任務、郵件、日程、清單、高級目標等。不過在確定接下來該干什么，在對任務、郵件的組織和分類方面，許多工程師都有一個 “層次化” 機制。

快速失敗與迭代

我會盡量快速調整代碼，哪怕自己不能確定那是（獲得注釋的）最優方案。對于想法的嘗試，我寧愿快速失敗而不愿先 100%考慮清楚

—Ari Chivukula

代碼嚇不倒我，我可以很容易進入狀態?，兵來將擋水來土掩

—?Michael Novati

許多工程師（包括我自己在內）可能會隱瞞的一點是害怕失敗。馬上就要做出完美產品的想法是可怕的，會導致我們考慮太多的問題。要養成在不知道結果會怎樣的情況下馬上寫代碼的習慣，這樣我們就可以更快地迭代，更快看到結果。

工作 / 生活平衡

有一位比你還要努力的《重要他者》是有幫助的，不然的話你就得自己扛了。我的做法是張弛有度，有時候我會沖刺一段時間然后放松一下。大概是高強度 2 個月然后放松 1 個月這樣子。在我看來，這要比 3 個月保持相同節奏更高效（不過這一點并不適合每個人），因為工作不是線性的。

—匿名

“洗澡的時候考慮問題” 這個比喻還是有點道理的

—?Adam Ernst

這些工程師的確干活非常努力。為了完成大量的代碼他們花費了很多的時間。盡管我沒有具體詢問工作 / 生活平衡的問題，但是他們當中很多人工作、生活是分得很清楚的，哪怕是 “全力以赴” 的工程師，這點挺讓我驚訝的。看起來這些人不僅可以高效工作，而且工作 / 生活平衡也能做得很好—如果愿意的話。

零星想法

你希望別人怎樣待你，你就該怎樣去對待別人。你得成為別人希望共事的那種工程師，而這大部分是通過反饋來了解的。要早點問，經常問，被問到的人會感覺自己受重視。

—?Ari Chivukula

經過這些訪談后，我感覺自己的開發進程正在一點一點地發生演變（同事要很努力才能引起我的注意，因為我現在戴上去噪音耳機了）。拆分 diff，請求評審，待辦事宜清單，這些東西我之前也做，但現在我知道如何更有效地利用這些工具了。說實話，采取了上面的做法之后，我的效率提高了不少。