Facebook 工程師是如何高效工作的？

Facebook 的工程師有哪些高效工作的經(jīng)驗呢溉箕？軟件工程師訪談了多位 Facebook 的高產(chǎn)工程師晦墙，總結了他們的共同經(jīng)驗以及晉級之路，供各位參考肴茄。

成為高效開發(fā)者這件事你可以通過經(jīng)驗晌畅、書本、或者試驗和錯誤來學習寡痰。但成為高效開發(fā)者的最有效方式之一是直接向高效開發(fā)者學習抗楔。我訪談了 Facebook 的幾位最高產(chǎn)的工程師，想找到這些開發(fā)者實現(xiàn)最高生產(chǎn)力的基礎結構是什么拦坠。

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

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

避免開會

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

—匿名
許多工程師都強調(diào)必要的時候會議是有用的郑气。但是必須對開會保持批評性的眼光，不開不必要的會腰池。

準備好做小任務

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

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

戴上噪音消除耳機

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

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

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

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

—Bob Baldwin
實際上 “正常” 工作時間內(nèi)我干不了什么事情条霜，只有靠加班時間才能完成事情

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

—匿名
我得承認，跟這幫工程師聊的最大發(fā)現(xiàn)之一是他們當中許多都工作很長的時間宰睡。為什么他們要干那么久呢蒲凶？原因挺有趣的。因為只有在早上拆内、深夜旋圆、周末這些時間才沒人打擾他們。通過尋找一天當中受打斷最小的時間麸恍，這些人得以推進自己的重大任務灵巧，把代碼給弄出來。

減少煩人的郵件 / 通知

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

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

不要失去狀態(tài)

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

—?Michael Novati
永遠要在一項相當簡單或機械的任務中結束一天董济。這讓你第二天很容易就可以撿回來恢復工作狀態(tài)步清，而不是又要從頭開始。

—Adam Ernst
對于我來說虏肾，當我在認真思考問題時廓啊、被打斷時、忘記自己在想什么時就會在編程方面會失去狀態(tài)封豪，也就意味著我需要重新把整個思考過程再過一遍谴轮。
當你在工作狀態(tài)時遇到干擾最好的辦法之一是推遲干擾。如果你在全神貫注的時候被干擾吹埠，那就告訴那個人你稍后會處理第步，速記一下此事，然后繼續(xù)工作直到你到達合理的停止點缘琅。一旦到達停止點粘都，馬上處理完堆積的那些事情。
如果干擾無法推遲刷袍，也有很多辦法可以 “保持狀態(tài)”翩隧。比如寫下自己當前的思考過程，寫下失敗測試呻纹，或者簡化正在思考的問題鸽心。

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

好代碼意味著很多東西。好代碼應該是功能性的居暖，容易評審的顽频，經(jīng)得起時間考驗的，等等太闺。

寫更小的 Diff

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

—匿名
我訪談的每一位工程師都非常強調(diào)把代碼變更拆分為邏輯模塊糯景，這樣可以讓其他人更容易理解，更快接受省骂。通過減少 diff 帶來的認知負荷蟀淮，評審者對于接受變更會更有信心。此外钞澳，通過減少 diff 的規(guī)模怠惶，變更對于評審者來說也沒那么令人望而生畏，這樣評審效率也會更高轧粟。
可以告訴你們的是策治，這篇文章問到的工程師都是過去 6 個月Facebook 里面提交 diff 最多的人脓魏。可能會有兩種風格的工程師群體通惫，一群是提交很多小的 diff 的茂翔，一群是提交數(shù)量較少但規(guī)模較大的 diff。

堆疊 diff 以及多任務處理

大多數(shù)工程師提到自己會將 diff 變更相互堆疊起來履腋，逐步建立 diff 間的邏輯依賴：
有時候當我做了一個規(guī)模很大的 diff 時珊燎，我會回過頭把它拆分成一系列邏輯步驟，這樣我就能慢慢變更一些東西遵湖，然后代碼的總體質(zhì)量也會逐步得到改善

—匿名
我從來不堆疊 diff悔政，相反，我會并行做幾樣獨立的事情延旧，然后在等待評審的時候交替處理卓箫。把一項大的變更分解成獨立部分這種做法也很有效，比方說增加界面垄潮，增加端結點烹卒，把這些事情安插進待辦事宜里面……這樣可以把事情堆起來交替做，不用在 diff 之間產(chǎn)生嚴重依賴弯洗。對代碼進行結構化旅急，這樣就不必堆疊或者弄子分支出來，評審牡整、交付藐吮、還原都容易一些。

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

—匿名
要做小的，至少是容易評審的 diff沐扳。這不僅是為了更容易更快地審核泥从，也能讓我寫出更好的代碼，因為我認為如果每次處理的東西邏輯分明的話沪摄，浪費的調(diào)試時間就非常少了躯嫉。此外對堆疊 diff 的經(jīng)驗可以可以讓小的 diff 可管理。

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

—匿名
無論工程師是使用堆疊 diff 還是進行 diff 的多任務處理帆阳，其生產(chǎn)力似乎都相當出色，這說明這兩種辦法對提高效率都很有效屋吨。

單元測試

測試規(guī)模要盡可能小蜒谤，這樣我會感覺舒服一點山宾。

—Michael Novati
大家對經(jīng)過單元測試的代碼更容易接受些。

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

溝通

對于比較棘手的 diff翎猛，我會適當增加幾個評審人胖翰，把 diff 共享到合適的群里面。不管有沒有動作切厘，我每天都會 ping 一個 diff 出來萨咳。如果好幾天都沒有動作，我會問評審的對 diff 有什么驚人的發(fā)現(xiàn)疫稿，然后對結構做出改變培他。最后我會盡可能跟對方多溝通。我總是以 “[產(chǎn)品 / 標簽]” 作為標題開頭—這樣大家就能知道 diff 是做什么的遗座，如果我想盡快得到接受舀凛，我會寫上 “[product-ASAP]” 或者 “[product-PUSHBLOCKER]” 之類的東西。

—?Michael Novati
這一點似乎顯而易見途蒋，但是就 diff 評審進行溝通的方式有很多種猛遍。一般的經(jīng)驗法則是按 diff 來進行。如果審核你的 diff 的人平時不怎么跟你打交道的話号坡，你可能要在描述和標題上面增加一些平時跟團隊成員溝通時不需要的上下文信息懊烤。你還可以在需要別人重點審查的地方做批注，如果相關邏輯比較復雜的話宽堆。
在設計會議上就提出期望還可以簡化寫代碼的過程腌紧，開發(fā)出好的 API 和架構等。
不要害怕提醒評審者注意你的 diff畜隶。如果他們不想審核你的 diff寄啼，他們可以退出或者建議其他人來做。如果讓 diff 一直留著待審查隊列代箭，那無異于給將來埋下沖突墩划。

第三級：具備團隊精神

編碼是一項團隊運動，就像所有的團隊運動一樣嗡综，個人能實現(xiàn)的事情總是有限的乙帮。

評審他人的代碼

快速掃描，通讀极景，打補丁察净，測試驾茴，評論

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

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

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

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

對自己在做什么要透明

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

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

提供好的反饋

專注于提供高質(zhì)量的反饋而不是挑刺拗引。如果你發(fā)現(xiàn) bug 了就指出來借宵，但是要相信工程師已經(jīng)測試過（并且相信他們會改正任何發(fā)現(xiàn)的 bug）

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

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

請求變更

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

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

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

不知道要承認

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

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

第四級：組織與推進

待辦事宜

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

—?Michael Novati
大多數(shù)情況下暗赶，我問到的工程師每個人都會使用不同的任務跟蹤工具鄙币。同時要跟蹤管理的來源還包括紙、任務蹂随、郵件十嘿、日程、清單岳锁、高級目標等绩衷。不過在確定接下來該干什么，在對任務激率、郵件的組織和分類方面咳燕，許多工程師都有一個 “層次化” 機制。

快速失敗與迭代

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

—Ari Chivukula
代碼嚇不倒我嘉冒，我可以很容易進入狀態(tài)?曹货，兵來將擋水來土掩

—?Michael Novati
許多工程師（包括我自己在內(nèi)）可能會隱瞞的一點是害怕失敗。馬上就要做出完美產(chǎn)品的想法是可怕的讳推，會導致我們考慮太多的問題顶籽。要養(yǎng)成在不知道結果會怎樣的情況下馬上寫代碼的習慣，這樣我們就可以更快地迭代银觅，更快看到結果蜕衡。

工作 / 生活平衡

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

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

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

零星想法

你希望別人怎樣待你,你就該怎樣去對待別人如筛。你得成為別人希望共事的那種工程師，而這大部分是通過反饋來了解的抒抬。要早點問杨刨，經(jīng)常問，被問到的人會感覺自己受重視擦剑。

—?Ari Chivukula
經(jīng)過這些訪談后妖胀，我感覺自己的開發(fā)進程正在一點一點地發(fā)生演變（同事要很努力才能引起我的注意，因為我現(xiàn)在戴上去噪音耳機了）惠勒。拆分 diff赚抡，請求評審，待辦事宜清單捉撮，這些東西我之前也做怕品，但現(xiàn)在我知道如何更有效地利用這些工具了。說實話巾遭，采取了上面的做法之后肉康，我的效率提高了不少。
附注：

• 1灼舍、Diff：Facebook 工程師所謂的 diff 是指用開源工具 phabricator 創(chuàng)建的代碼修訂（differentialrevision）吼和。這些修訂是放進 phabricator 供其他工程師評審的代碼改動。工程師可以評論骑素、請求變更或者接受代碼變更炫乓，之后再轉給產(chǎn)品影響實際用戶。Facebook 編寫的每一條代碼都要經(jīng)過這一驗證步驟，確保工程師之間的不斷協(xié)作以及相互反饋末捣。*
• 2侠姑、堆疊 Diffs：是指 diff 的堆疊，上層 diff 邏輯依賴于下層 diff箩做，其功能是基于所有下層 diff 的功能基礎之上開發(fā)的莽红。這使得工程師可以在方便評審的簡單小規(guī)模的變更基礎上開發(fā)功能，循序漸進實現(xiàn)更大的目標邦邦。*
  分享自：
  1：medium.freecodecamp.com安吁。
  2：36Kr。