Kent Beck在Facebook七年期間，目睹Facebook團隊從700人擴展到5000多人，如果100,000名工程師如何在同一系統上工作？

Facebook的軟體工程工作流程相當傳統：

1.創建差異。

2.獲得審核和批准。

3.把它投入生產。

4.監控意外後果。

與許多代碼審查批准工作流程一樣，審核步驟引入了不可預測的延遲，導致：

1.較大的差異

2.累計巨大差異

3.多任務處理

關鍵問題是如何在一份代碼上合併多個程序員的差異？這個問題其實有點類似技術上分散式事務，如何在多個伺服器上複製一樣的狀態？關鍵是每個伺服器的狀態都在變化？

人們代碼提交越頻繁，越容易發生代碼衝突，代碼結構如同一個樹形結構，某個分支不同，導致後續非常不同，這是不是有些類似區塊鏈，區塊鏈是通過嚴格控制區塊號的順序實現的，但是在代碼協作中，人不是機器，無法排隊領號，或者搖號。這會阻止人們的創造精神。

Kent Beck系統找到一種通過減少合併代碼變化並提高變化傳播的速度和範圍來擴展軟體項目協作的策略。人們能夠越頻繁提交，同時將自己的改變快速擴展到其他人代碼中，他借用Limbo歌曲中一句話：

How low can you go? 命名這種策略為Limbo。

他提出一個test && commit || revert的具體做法實現Limbo策略：

作為容易操作Limbo策略一部分，我們發明了一種新的編程工作流程。我介紹了「test && commit|| revert」，代碼每次運行測試代碼正確後都會被提交，如果測試失敗，則代碼返回到測試最後通過的狀態。

Limbo通過立即傳播微小變化來擴展技術協作。而傳統TDD測試驅動開發將無法在Limbo中運行，在自己的代碼變化傳播給其他人之前，所有測試都必須通過。

在Git中實際命令是：

git commit -am working
git reset --hard

有人做了一個JS開源項目limbo-js：

import { exec } from "child_process"
while (true) {
await exec("git pull --rebase -q")

try {
await exec("npm test")
await exec("git add -A && git commit -q")
} catch {
await exec("git reset --hard -q && git clean -fdq")
}

await exec("git push -q")
}

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！