兔子运送胡萝卜_一次运送一个重构并提供一个小片段，以降低风险

兔子运送胡萝卜

您不需要完成一项功能，您的用户也不需要看到它就可以发布并开始对其进行战斗测试。 尽可能对其切片，并尽快释放块以缩短反馈循环并降低风险。

我的同事们一直在努力进行我们网店中的一项重大更改-用新的旧购物车和结帐流程代替我们的旧购物车和结帐流程，并实现此更改所能实现的一些新的，高度期望的功能。 我们决定通过仅对产品配件进行更改来降低更改的风险。 但是，企业希望包含新功能，并且需要更改UI。 但是UI必须在所有部分中保持一致，因此我们在上线之前也需要对主要产品实现它-这将有必要也实现主要产品所使用的更复杂的过程（尚未得到新后端的支持） 。 突然之间，我们的工作量很大，需要数周才能完成，并且会在大规模的部署中发布。

如此大规模且耗时的更改没有任何来自现实的反馈，然后立即将其全部发布，对我们的所有销售都产生了影响–我发现这确实很可怕（ 并且之前也曾为此奋斗过 ）。 从本质上讲，这是数周的风险，然后将其释放到一个大爆炸中。 我们如何分解它，将其切成小块，而又不会使商人感到不高兴？

然后我们意识到，我们不需要同时进行“重构” ¹ （引入新的客户端购物车并切换到新的后端）和新功能。 而且，我们可以像应用程序一样，首先让新购物车与旧后端通信，然后，也许并行地，也开始与新后端通信（ 请参阅并行更改 ）。 我们不需要更改UI，用户也不需要注意有任何更改。 因此，这成为了我们的新战斗计划：

1. 实施新的客户端购物车，即UI存储用户选择的对象的对象，然后最终将其发送到旧的后端； 保持结帐流程不变。 最初仅对配件执行此操作
2. 以后也将其扩展到主要产品
3. 逐步集成新的后端，同时与使用旧的后端进行对话； 逐步切换到新的
4. 随处实施新的用户界面
5. 实施新功能

（某些步骤可能会交织在一起，因此我们有一定的试验和发现自由权。）每个步骤，甚至其中的一部分，都将尽快发布到生产中，以便在下一个块到达时进行实战测试。 风险和不确定性被最小化，我们几乎总是在生产代码上工作。

PS：非常感谢Alex York和我的其他同事的帮助

¹可以说这不是（仅仅是）重构，因为我们不仅仅更改内部结构。

翻译自: https://www.javacodegeeks.com/2015/09/shipping-a-refactoring-feature-one-tiny-slice-at-a-time-to-reduce-risk.html

兔子运送胡萝卜