如何从精益思想引出 TDD？

[JimmyLv]

PDCA 里面plan就是tasking产出test case，do就是写代码，check就是bad smell，然后action当然就是重构！

但是 🐻 叔说 PDCA 太老了，大家都知道。

所以改用精益模型… 缩短build measure learn的反馈周期。

其他几个模型：

PDCA: Plan--Do--Check--Adjust

Ray Dalio 的五步流程法GPDDD: Goal--Problems--Diagnosis--Design--Doing

Eric Rise的精益创业理论DBML: Define--Build---Measure--Learn

孙陶然的16字方法论： 先问目的、再做推演、亲手打样、及时复盘

https://mp.weixin.qq.com/s/VUHRvx-Ny5mnlO5GkJjPLA

[JimmyLv]

如何从精益引出 TDD？

• 精益跟TDD有什么关系？（思想上、流程上）
• 如何在TDD中运用精益思想改进流程？

[JimmyLv]

写测试（其实是Tasking），然后写代码，不需要让Testing通过，也是一种TDD。

这是tdd的工作原理和精髓，但不是tdd

精髓就在这里，作者很皮呀。不过我觉得非常有道理，testing 有了，driven 也有了，development也出来啦。

_{Sent with GitHawk}

[JimmyLv]

节奏的重要性，再怎么强调也不为过。

最近在整一个preview功能，一不小心就跌进死胡同，很难再绕出来，且思维狭隘，只朝着一个方向走到死。这时候需要休息，需要打开思路，见招拆招，且需要commit，一步一个脚印。

啊，花了快两天，终于算是整出来了，还是编译+runtime结合的方案。

其实TDD的tasking可以促使我去思考5W1H，即preview参数从何而来，这是这次遇到问题的关键所在。同时，还需要更关注于输入/输出，输入的来源和变化都可能导致方案选型的不同。

再者，在确定几种方案之后，应当对其进行横向对比，从最简单的方案开始实现，然后进一步优化。当然，有可能某些方案根本行不通，那自然应该给每种方案设立timebox，在指定时间内无法达成效果，就应该选择另外一条路。

_{Sent with GitHawk}

[JimmyLv]

https://github.com/JimmyLv/tdd-with-react.workshop