记一种TDD方式:红绿憋,红绿再憋
来源:互联网 发布:2013淘宝男装店铺排行 编辑:程序博客网 时间:2024/04/30 07:36
前段时间看到微博上看到一则冷笑话,讲的是如何画马:
我看到前半截的时候,我还真的在纸上用笔一点点的画,但是当我看到最后一步的时候,WHAT THE FUCK!!!
这种方式的“画马”不仅仅存在在画画上,也存在在我们平常的工作中,比如如何使用TDD上。
和其他人pair的过程中,我发现很多人对于TDD的理解就是简单的“先写测试”。
他们知道TDD,于是他们先写一个测试,然后眼睛对着电脑,开始憋,憋,憋。
憋了十多二十分钟,磕磕盼盼的敲了实现代码。
绿了,通过了,谢天谢地!
再然后,写下一个测试,然后又开始憋,憋,憋。
憋了十多二十分钟,想了下,把已有的实现删了,再重新整一个。
好一会儿,又弄出来了。
第三个测试,开始,憋,憋,憋。
弄不出来了,WHAT THE FUCK!!!
所以,传统的TDD Lifecycle从“红绿重构、红绿再重构”变成了“红绿憋、红绿再憋”
如果你发现你用这样的方式进行TDD,那你可以检查两件事情你有没有做好:
第一,有没有Tasking?
第二,有没有选择最简单的Task先做?
为什么要Tasking?
Tasking就是将一个原本的较大的需求,分解成一个个很小的需求。实现一个大的需求,往往需要比较长的时间。但是如果实现一个很小的需求,小的不能再小的需求时,往往是非常容易的。通过这样的方式,可以缩短我们红绿重构的周期,得到快速的反馈。如果Tasking后的需求粒度不够小,我们就会进入“红绿憋”的循环。
这里需要注意的是Tasking不是实现过程的拆分,而是需求的拆分。
为什么要选择最简单的Task先做?
有人说,对啊,我Tasking了啊!我也TDD了啊!我还是在憋啊!
这时候,问题往往出在你选择什么样的Task作为当前的Task。一般来说,简单的Task对应简单的实现,复杂的Task对应复杂的实现。并且复杂的Task往往涵盖了简单的Task。所以,选择简单的Task,后实现复杂的Task,已有的简单Task的实现将有助于让复杂的Task实现变得更容易。反之,如果首先实现了复杂的Task,那么你的代码可能将会陷入某种不必要的抽象,再实现其他的Task时,可能就需要重写。
于是,问题变成了,什么是“简单”的Task呢?什么又是“最简单“的Task呢?
一言蔽之,就是你能用最短时间实现的Task。
更多关于如何选择最简单的Task,以及更多思考,呕血推荐阅读企业级软件开发大师Uncle Bob提出的TPP(Transform Priority Premise)。
- 记一种TDD方式:红绿憋,红绿再憋
- TDD
- TDD
- TDD
- TDD
- 换一种方式生活
- 一种缺陷分类方式
- 弹出对话框一种方式
- 一种字母排序方式
- 一种字母排序方式
- 一种思维方式
- 推荐一种权限方式
- 变换一种方式
- 换一种思维方式
- 博客,一种成长方式
- MVP 一种实现方式
- 截屏一种方式
- 一种赋值方式
- Unable to execute dex: java.nio.BufferOverflowException
- 数字图像处理—算术运算基本作用及模板(样板,窗口,滤波器)运算
- UVa10120 - Gift?!
- 篮桥杯,翻硬币 (贪心)
- 黑马程序员_多线程2
- 记一种TDD方式:红绿憋,红绿再憋
- POJ 2559 单调栈
- WPF设置Image控件的图片淡入淡出更换
- 副老大的待遇
- Remove Duplicates from Sorted Array - LeetCode
- OpenThreads
- [IOS]UITextField中设置placeholder字体颜色
- WinSock网络编程学习(二)计算校验和程序
- Construct Binary Tree from Inorder and Postorder Traversal