Kent Beck的test && commit || revert 敏捷協作方法

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開源專案ofollow,noindex" target="_blank">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')
}