jimmylv.github.io
jimmylv.github.io copied to clipboard
如何从精益思想引出 TDD?
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
如何从精益引出 TDD?
- 精益跟TDD有什么关系?(思想上、流程上)
- 如何在TDD中运用精益思想改进流程?
写测试(其实是Tasking),然后写代码,不需要让Testing通过,也是一种TDD。
这是tdd的工作原理和精髓,但不是tdd
精髓就在这里,作者很皮呀。不过我觉得非常有道理,testing 有了,driven 也有了,development也出来啦。
Sent with GitHawk
节奏的重要性,再怎么强调也不为过。
最近在整一个preview功能,一不小心就跌进死胡同,很难再绕出来,且思维狭隘,只朝着一个方向走到死。这时候需要休息,需要打开思路,见招拆招,且需要commit,一步一个脚印。
啊,花了快两天,终于算是整出来了,还是编译+runtime结合的方案。
其实TDD的tasking可以促使我去思考5W1H,即preview参数从何而来,这是这次遇到问题的关键所在。同时,还需要更关注于输入/输出,输入的来源和变化都可能导致方案选型的不同。
再者,在确定几种方案之后,应当对其进行横向对比,从最简单的方案开始实现,然后进一步优化。当然,有可能某些方案根本行不通,那自然应该给每种方案设立timebox,在指定时间内无法达成效果,就应该选择另外一条路。
Sent with GitHawk
https://github.com/JimmyLv/tdd-with-react.workshop