从思维角度看有些编程技巧

我经常建议程序员在写类和方法时，把内容一条一条列出。
1.买花。
2.取钱。
3.订餐。
4.打的去餐馆。
不一定非得测试驱动，我觉得这更像是理思路，计划驱动。
即使写一小段程序，稍微计划一下的效果也是非常好的，避免遗漏，思维缜密。

你的计划从哪里来？就是从你要的结果来。

首先：
这次行动有必要吗？
这是那种类型的妞?需要啥？
原来哪次泡妞的经验和教训可参考？
需不需要请教个情圣或者google一下？

然后才是安排行程。

我觉得程序员有点美学和艺术修养是必要的。经常看见那种程序，你说它有问题吧,又没问题，但写的一塌糊涂,有种满腔悲愤的感觉。

这个比喻有意思
测试驱动在很多时候只是了起到test及Demo的作用，更多应体会到驱动才是它最本质的东西。

我很想研究TDD,每次着手写Test的时候又不知该如何下手,面对着紧急的任务,不仅要设计一个灵活的结构,还要拿出本来就非常有限的时间写Test, 不知道各位有没有什么经验,共享共享~~~~

简单说一句，测试先行中测试就是需求
T-E时，如果测试通过了，他所告诉你的只是你的程序确实得到了这样的结果。哦是的他可以运行。
T-F时，如果测试通过了，他告诉你的不只是你的程序可以运行，而是你的程序是符合需求的。
T-F在没有任何一行代码的时候，你写出的测试就是你的目的！

晕有点跑题哈~~

小的方面这么干没有问题,大的方面往往需要飘逸一些,因为往往根本就确定不了目的.
就好像女友说想要一只狗狗, 于是你问,想要什么狗狗阿?
她来句,就是普通的狗狗,可爱就行.
然后你查遍了资料,逛遍了狗市.已自己认为她喜欢的想法买了一只回去.
结果女友看到说, 哦 我喜欢个头比着大点的, 毛比这长点的 颜色比这深点的 尾巴比这长点的 脸比这瘦点的.......
于是呼，重买。
再交货之，女友说 哦 我想了想，邻居都是小狗 我要大狗不好 %￥—*……  夏天 毛长很热的 ￥%……￥—  .........

没错，但你说的是弄清需求方面的问题。
我这里谈的只是需求确定下来，开始实现之后的一个技巧而已。

这个讲法我非常同意。因为在没有做软件的时候，我的习惯就是把一些容易忘记的东西全部记下来。当然不写下来也行，但是要用思维导图或者树性思维的方式去记，不然一团乱麻很难记得下来。
    所以说不管是测试驱动也好，还是制定计划也好，这都不是软件行业的专利，而是一个很古老但很有用的方法。只是大多数的写代码写得晕掉的程序员全部忽略掉了这一点了。所以说一个好的程序员并不一定是一个“法拉利”级的“软件制造引擎”而应该是一个迈凯伦或者Microsoft电子工程子公司级的ECU。