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开源项目 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')
}