f*****0
发帖数: 166 | 1 各位大牛，
最近我在自学Java 编程，读到一本书，head first software development. 里面提到
软件开发流程，包括“user stories""iteration"，“documentation”，“test
drive development” 以及 "deliver"等等。
我想知道这个开发流程是不是大家都会真正在实践中采用和遵循（比方说从user
stories开始估计时间需求，整个开发分成几个iteration等等），还是，基本上自己想
怎么开始就怎么开始？还有，大家都会用test-drive development 来开发编程吗？
敬请指教。 |
d**********x
发帖数: 4083 | 2 老实说我觉得现在软件工程还处于一个非常早期的发展阶段
一部分原因是前些年工业上的模式变化太快，研究跟不上现实
这些方法算是在实践中总结出来的一些大体上行之有效的办法，也在各种企业中被部分
地广泛应用，但是没人能找到一个普适的方法。。
总之，企业里面会用这些，个人开发一般就是瞎搞搞，要不不是给自己添堵么。。
btw,这里面的test drive development我感觉不应该和其他的并列，test drive dev我
更倾向与认为它是一种快速车代码的辅助技术
【在 f*****0 的大作中提到】
: 各位大牛，
: 最近我在自学Java 编程，读到一本书，head first software development. 里面提到
: 软件开发流程，包括“user stories""iteration"，“documentation”，“test
: drive development” 以及 "deliver"等等。
: 我想知道这个开发流程是不是大家都会真正在实践中采用和遵循（比方说从user
: stories开始估计时间需求，整个开发分成几个iteration等等），还是，基本上自己想
: 怎么开始就怎么开始？还有，大家都会用test-drive development 来开发编程吗？
: 敬请指教。
|
f*****0
发帖数: 166 | 3 感谢指点。
我现在在摸索去公司做软件开发的可行性。所以看到了这本书。根据你的看法，企业里
还是会用的。如果自己没有这方面的经验（或是自己实践），即使找到了类似的工作，
大概开始时也会非常痛苦吧？
关于test-drive development,作为一种辅助技术，实践中用得多吗？
【在 d**********x 的大作中提到】
: 老实说我觉得现在软件工程还处于一个非常早期的发展阶段
: 一部分原因是前些年工业上的模式变化太快，研究跟不上现实
: 这些方法算是在实践中总结出来的一些大体上行之有效的办法，也在各种企业中被部分
: 地广泛应用，但是没人能找到一个普适的方法。。
: 总之，企业里面会用这些，个人开发一般就是瞎搞搞，要不不是给自己添堵么。。
: btw,这里面的test drive development我感觉不应该和其他的并列，test drive dev我
: 更倾向与认为它是一种快速车代码的辅助技术
|
c*********e
发帖数: 16335 | 4 java更多的是开发j2ee网站，写个shopping cart,用spring,hibernate.
这是它的强项。做游戏，c++,objective-c都不错。
【在 f*****0 的大作中提到】
: 各位大牛，
: 最近我在自学Java 编程，读到一本书，head first software development. 里面提到
: 软件开发流程，包括“user stories""iteration"，“documentation”，“test
: drive development” 以及 "deliver"等等。
: 我想知道这个开发流程是不是大家都会真正在实践中采用和遵循（比方说从user
: stories开始估计时间需求，整个开发分成几个iteration等等），还是，基本上自己想
: 怎么开始就怎么开始？还有，大家都会用test-drive development 来开发编程吗？
: 敬请指教。
|
d**********x
发帖数: 4083 | 5 没关系，流程这东西，如果你不是做pm或者manager的话，跟着team走就行，对agile里
面那些东西基本有个概念，不是别人说个名字就抓瞎就行，不同的地方都有不同的习俗
，没必要抠太细
test-drive实践中用的有多少，统计上我还真不是很确定，但是我知道一般人用过之后
会上瘾
。。。
部分
dev我
【在 f*****0 的大作中提到】
: 感谢指点。
: 我现在在摸索去公司做软件开发的可行性。所以看到了这本书。根据你的看法，企业里
: 还是会用的。如果自己没有这方面的经验（或是自己实践），即使找到了类似的工作，
: 大概开始时也会非常痛苦吧？
: 关于test-drive development,作为一种辅助技术，实践中用得多吗？
|
d**********x
发帖数: 4083 | 6 做小游戏用flash...
【在 c*********e 的大作中提到】
: java更多的是开发j2ee网站，写个shopping cart,用spring,hibernate.
: 这是它的强项。做游戏，c++,objective-c都不错。
|
f*****0
发帖数: 166 | 7 感谢你在本版以及programming版都回复指点。
那多数的Java programmer 都会朝j2ee网站开发方向发展吗？
【在 c*********e 的大作中提到】
: java更多的是开发j2ee网站，写个shopping cart,用spring,hibernate.
: 这是它的强项。做游戏，c++,objective-c都不错。
|
f*****0
发帖数: 166 | 8 哇，那就是说test-drive dev 还是很有市场以及收益了。多谢多谢。
【在 d**********x 的大作中提到】
: 没关系，流程这东西，如果你不是做pm或者manager的话，跟着team走就行，对agile里
: 面那些东西基本有个概念，不是别人说个名字就抓瞎就行，不同的地方都有不同的习俗
: ，没必要抠太细
: test-drive实践中用的有多少，统计上我还真不是很确定，但是我知道一般人用过之后
: 会上瘾
: 。。。
:
: 部分
: dev我
|
m*****u
发帖数: 1342 | 9 Test driven is quite useful, actually, esp. the automated unit test and if
you can create test cases from requirements or from bug reports. It does not
guarantee you the software you are developing are bug-free, but it does
give you more confidence when you fix bugs/add new features.
【在 f*****0 的大作中提到】
: 各位大牛，
: 最近我在自学Java 编程，读到一本书，head first software development. 里面提到
: 软件开发流程，包括“user stories""iteration"，“documentation”，“test
: drive development” 以及 "deliver"等等。
: 我想知道这个开发流程是不是大家都会真正在实践中采用和遵循（比方说从user
: stories开始估计时间需求，整个开发分成几个iteration等等），还是，基本上自己想
: 怎么开始就怎么开始？还有，大家都会用test-drive development 来开发编程吗？
: 敬请指教。
|
c*****e
发帖数: 3226 | 10 tdd 就是那帮脑袋进水显得自己忙呼呼的大公司的manager 搞出的最傻冒的process,
你看那个start~up 搞tdd? 这个星期出不了feature你就滚蛋，谁有闲工夫去 follow
tdd 写一堆没用的test cases ?
【在 f*****0 的大作中提到】
: 哇，那就是说test-drive dev 还是很有市场以及收益了。多谢多谢。
|
|
|
d**********x
发帖数: 4083 | 11 ……
tdd的最简化版用法(省略掉重构)：
1. 写一个method，在unit test里面写两句，要求这个method基本可用
2. 实现这个method，使其通过unit test
3. 重复以上动作
实际上这种事情你直接车代码也是一样要做，只是变成
1. 写一个method
2. 执行一下程序，手工输一个test case，看看能用否
重复以上动作
你觉得第二种方法一定比第一种快？
我还是认为无论是代码质量还是开发效率，tdd都是优于那种写代码-执行-测试的传统
手段的。
不过我因为种种原因并不怎么实践这玩意。。。
follow
【在 c*****e 的大作中提到】
: tdd 就是那帮脑袋进水显得自己忙呼呼的大公司的manager 搞出的最傻冒的process,
: 你看那个start~up 搞tdd? 这个星期出不了feature你就滚蛋，谁有闲工夫去 follow
: tdd 写一堆没用的test cases ?
|
g*****g
发帖数: 34805 | 12 It's certainly more efficient in the long run, because your tests can be re-
run over time to prevent/reduce regression. Bugs found in development is
cheaper to fix than found by QA, much cheaper than found in production by
customer. Delivering less but solid features is much better than delivering
many but broken features.
I am not taking a test driven approach religiously. But I do think the
test drive approach is the right way. I typically would at least have tests
to cover the sunny day scenario. And I'll add a new test whenever I find a
bug.
【在 d**********x 的大作中提到】
: ……
: tdd的最简化版用法(省略掉重构)：
: 1. 写一个method，在unit test里面写两句，要求这个method基本可用
: 2. 实现这个method，使其通过unit test
: 3. 重复以上动作
: 实际上这种事情你直接车代码也是一样要做，只是变成
: 1. 写一个method
: 2. 执行一下程序，手工输一个test case，看看能用否
: 重复以上动作
: 你觉得第二种方法一定比第一种快？
|
d**********x
发帖数: 4083 | 13 agree.
re-
delivering
tests
【在 g*****g 的大作中提到】
: It's certainly more efficient in the long run, because your tests can be re-
: run over time to prevent/reduce regression. Bugs found in development is
: cheaper to fix than found by QA, much cheaper than found in production by
: customer. Delivering less but solid features is much better than delivering
: many but broken features.
: I am not taking a test driven approach religiously. But I do think the
: test drive approach is the right way. I typically would at least have tests
: to cover the sunny day scenario. And I'll add a new test whenever I find a
: bug.
|
b******b
发帖数: 713 | 14 just FYI, in morgan stanley/bank of america, most of server process is done
in java, including those with high performance requirements, like electronic
trading platform which handles thousands of millions of trades daily.
【在 c*********e 的大作中提到】
: java更多的是开发j2ee网站，写个shopping cart,用spring,hibernate.
: 这是它的强项。做游戏，c++,objective-c都不错。
|
t******y
发帖数: 748 | 15 任何工作上手，熟练都有过程。
test-drive development在实际工作中，尤其是开发新系统用的并不是很多。
但在某些企业重构软件时，是防止regression的重要辅助手段。
【在 f*****0 的大作中提到】
: 感谢指点。
: 我现在在摸索去公司做软件开发的可行性。所以看到了这本书。根据你的看法，企业里
: 还是会用的。如果自己没有这方面的经验（或是自己实践），即使找到了类似的工作，
: 大概开始时也会非常痛苦吧？
: 关于test-drive development,作为一种辅助技术，实践中用得多吗？
|
g*****g
发帖数: 34805 | 16 If you don't write the test cases during the new development, it's just not
possible to add adequate coverage later on. Nobody can write the unit tests
better than the original developer.
【在 t******y 的大作中提到】
: 任何工作上手，熟练都有过程。
: test-drive development在实际工作中，尤其是开发新系统用的并不是很多。
: 但在某些企业重构软件时，是防止regression的重要辅助手段。
|
t******y
发帖数: 748 | 17 I agree, but most of the dev don't write complete/formal unit test before
code complete due to deadline pressure. And BVT or test cases written are
normally used to prevent build break or major functionality break during
maintain or after 1st milestone.
Test coverage are never enough for a decent-sized software project. that's
why beta release, hot fix and on-call beepers are all part of the life cycle
. |
c*****e
发帖数: 3226 | 18 所以说好的程序员很重要，写完基本上就是bug free. 只需要做模块的function
testing.
你看开源的voip server freeswitch 根本就没unit testing. 没别的，写系统的元老
编程很强。
tdd 就是保证烂程序员也能出work的code的一种方法。
【在 d**********x 的大作中提到】
: ……
: tdd的最简化版用法(省略掉重构)：
: 1. 写一个method，在unit test里面写两句，要求这个method基本可用
: 2. 实现这个method，使其通过unit test
: 3. 重复以上动作
: 实际上这种事情你直接车代码也是一样要做，只是变成
: 1. 写一个method
: 2. 执行一下程序，手工输一个test case，看看能用否
: 重复以上动作
: 你觉得第二种方法一定比第一种快？
|
c*****e
发帖数: 3226 | 19
你这个假设是错的，为何写一个method就要测试一次？除非入门级的程序员。难道你面
试的时候说：哦，等一下，我写先写unit testing 看对不对，然后才能写下一个
method.
【在 d**********x 的大作中提到】
: ……
: tdd的最简化版用法(省略掉重构)：
: 1. 写一个method，在unit test里面写两句，要求这个method基本可用
: 2. 实现这个method，使其通过unit test
: 3. 重复以上动作
: 实际上这种事情你直接车代码也是一样要做，只是变成
: 1. 写一个method
: 2. 执行一下程序，手工输一个test case，看看能用否
: 重复以上动作
: 你觉得第二种方法一定比第一种快？
|
t******y
发帖数: 748 | 20 这样的程序员你得给多少银子。又得花多少心思才能在他高产的年龄留得住他呀！
所以说管理是艺术啊，没有通吃办法。
【在 c*****e 的大作中提到】
: 所以说好的程序员很重要，写完基本上就是bug free. 只需要做模块的function
: testing.
: 你看开源的voip server freeswitch 根本就没unit testing. 没别的，写系统的元老
: 编程很强。
: tdd 就是保证烂程序员也能出work的code的一种方法。
|
|
|
d**********x
发帖数: 4083 | 21 好吧，一般的“高手”写代码的时候都是脑子里面想两个test case，然后稍微验证一
下就接着往下跑。这适合短的method，如果是几十行上百行的method，我不信你连基本
的功能测试都不做就敢说我这玩意一定work，我看要不是java，连编译能过都未必能保
证。
这确实有一个好处，就像peopleware里面说的，编程是一个要求不被打断的高度集中的
工作，如果一直在这条逻辑线里面工作，人的效率会比较高
但是另一方面，如果工具熟练的话，写unit test不过是把脑子里面的test case
formalize下来了，我仍然不认为这是一个严重的overhead。
【在 c*****e 的大作中提到】
:
: 你这个假设是错的，为何写一个method就要测试一次？除非入门级的程序员。难道你面
: 试的时候说：哦，等一下，我写先写unit testing 看对不对，然后才能写下一个
: method.
|
d**********x
发帖数: 4083 | 22 C++代码百万行没有单元测试的比比皆是
然后还维护，维护个屁，一个bug修一天。
【在 t******y 的大作中提到】
: 这样的程序员你得给多少银子。又得花多少心思才能在他高产的年龄留得住他呀！
: 所以说管理是艺术啊，没有通吃办法。
|
f*****0
发帖数: 166 | 23 感谢楼上几位大牛的热心指点讨论，在下受教了。我的现在认知：TDD作为一种开发模
式，可以有助于有效，快速，代码简洁的完成功能需求， 特别是对于相对缺乏经验的
程序员。熟练掌握使用后，测试和开发自然而然同步进行。缺点就是也许会需要更多的
时间。不过，对于经验不足的程序员，直接编程或许需要花更多的时间来测试。 |
g*****g
发帖数: 34805 | 24 Such developer doesn't exist, period. It's either they didn't include the
unit tests with the source. Or they had been through thorough QA cycle.
【在 c*****e 的大作中提到】
: 所以说好的程序员很重要，写完基本上就是bug free. 只需要做模块的function
: testing.
: 你看开源的voip server freeswitch 根本就没unit testing. 没别的，写系统的元老
: 编程很强。
: tdd 就是保证烂程序员也能出work的code的一种方法。
|
g*****g
发帖数: 34805 | 25 不是说每个方法都要写测试。但如果主要的流程连个测试都没有，稍微改点东西就祈祷
吧。
【在 d**********x 的大作中提到】
: 好吧，一般的“高手”写代码的时候都是脑子里面想两个test case，然后稍微验证一
: 下就接着往下跑。这适合短的method，如果是几十行上百行的method，我不信你连基本
: 的功能测试都不做就敢说我这玩意一定work，我看要不是java，连编译能过都未必能保
: 证。
: 这确实有一个好处，就像peopleware里面说的，编程是一个要求不被打断的高度集中的
: 工作，如果一直在这条逻辑线里面工作，人的效率会比较高
: 但是另一方面，如果工具熟练的话，写unit test不过是把脑子里面的test case
: formalize下来了，我仍然不认为这是一个严重的overhead。
|
g*****g
发帖数: 34805 | 26 一天能修好，那是真牛人。百万代码，没单元测试，就算知道哪里出问题，改起来也要
很小心。
【在 d**********x 的大作中提到】
: C++代码百万行没有单元测试的比比皆是
: 然后还维护，维护个屁，一个bug修一天。
|
c*****e
发帖数: 3226 | 27 where is the unit tesing code for linux kernel?
【在 g*****g 的大作中提到】
: 不是说每个方法都要写测试。但如果主要的流程连个测试都没有，稍微改点东西就祈祷
: 吧。
|
g*****g
发帖数: 34805 | 28 While kernel is special, in the sense that it heavily depends on device and
it relies on community testing, which is very different from application
written in Java. Test automation still exists.
http://ltp.sourceforge.net/
【在 c*****e 的大作中提到】
: where is the unit tesing code for linux kernel?
|
n*****3
发帖数: 1584 | 29 no unit test, it is dangerous to update code ,especially 百万代码 level.
【在 g*****g 的大作中提到】
: 一天能修好，那是真牛人。百万代码，没单元测试，就算知道哪里出问题，改起来也要
: 很小心。
|
b***i
发帖数: 3043 | 30 送你一句计算机高手梁肇新的名言，程序不是写出来的，而是调试出来的。
【在 c*****e 的大作中提到】
: where is the unit tesing code for linux kernel?
|
|
|
t******y
发帖数: 748 | 31 That's true.
Whether there is a requirement of test automation, there is always a step to
verify your code/change working efficiently.
TDD want to systematically ensure the efficiency at the very beginning.
But the extra time it spent at following complete TDD process may not meet
the business goal of a specific project.
Not all projects are large and requires upgrade continuously.
And also there are professional testers to help in large companies.
【在 b***i 的大作中提到】
: 送你一句计算机高手梁肇新的名言，程序不是写出来的，而是调试出来的。
|
c*****e
发帖数: 3226 | 32 他怎么个高法？还能高过linus ?
【在 b***i 的大作中提到】
: 送你一句计算机高手梁肇新的名言，程序不是写出来的，而是调试出来的。
|
b***i
发帖数: 3043 | 33 你编过多少行程序？
linus说过编程不用调试？
其实，梁肇新不见得不如linus。linus就是一个项目经理
【在 c*****e 的大作中提到】
: 他怎么个高法？还能高过linus ?
|
g*****g
发帖数: 34805 | 34 Linus这种级别的俺没见过。见过几个奥赛金牌的写程序，写得快，调试快。但没听说
写了就bug free的。 |
