和老板讨论开发模式

david(david) 10:15:27
用例要让他们自己写一下？
aya(aya) 10:15:38
效果不好.
aya(aya) 10:15:53
因为他们没编码之前,不知道怎么测试
david(david) 10:15:44
先写测试，后写代码
david(david) 10:16:03
这个是习惯问题
aya(aya) 10:16:21
不如就让他们先写代码,然后自己想办法去测试,然后我来看测试过程合不合理
aya(aya) 10:16:43
所以才要他们记录测试的过程.
david(david) 10:16:48
如果写完代码来测试
aya(aya) 10:17:03
不是习惯问题,是现阶段他们的能力和经验不够
david(david) 10:16:56
测试肯定是遵循他的代码来的
david(david) 10:17:01
bug肯定很多
aya(aya) 10:19:15
这个月先看看这样行不行. 从以前在华为的经验来看, 程序员经验不足的话,先写测试用例再编程的效果不好
aya(aya) 10:19:34
前面写测试用例的时间往往变成做无用功了
david(david) 10:20:13
应该有一个写测试用例的框架
aya(aya) 10:20:46
测试用例无非就是考虑覆盖度
aya(aya) 10:20:53
是语句覆盖还是条件覆盖
aya(aya) 10:21:25
力求测试时,可以将所有代码都执行过
david(david) 10:21:17
正如你说的，他们不会这么有经验去想全怎么覆盖的
david(david) 10:21:26
可以想多少，写多少
aya(aya) 10:22:25
基于覆盖度的测试我其实不认同的
aya(aya) 10:22:40
如果代码逻辑本身就有问题,覆盖了又能如何
david(david) 10:22:47
你现在这种开发，完全可以使用TDD，测试驱动开发的敏捷开发模式
aya(aya) 10:22:58
不如基于环境的测试, 基本环境OK, 边界条件不崩溃就好了
david(david) 10:23:37
你这样出来的东西，就是要靠日后更加多时间的bug定位来弥补
david(david) 10:23:45
就像现在出现了那个框
david(david) 10:23:54
不知道是什么原因的
aya(aya) 10:24:07
BUG是不可避免的
aya(aya) 10:24:30
敏捷我考虑过了
aya(aya) 10:24:37
我们组不具备敏捷的条件
aya(aya) 10:25:04
敏捷本身就要求开发人员是自主的,能力强的.
aya(aya) 10:25:34
你让其良或者豆丁去敏捷,不可能的.
david(david) 10:25:47
正是因为他们这样的能力，才要敏捷
aya(aya) 10:26:05
循序渐进吧
david(david) 10:26:00
敏捷是迭代开发，就是允许你想不全
david(david) 10:26:14
TDD就是一种循序渐进的方法
aya(aya) 10:26:33
一下子要变成流程很通畅的开发组,不太现实的.
david(david) 10:27:21
不要去抗拒。你先看看这种方式是否合适。
aya(aya) 10:27:36
这个月我就是想跟踪到每一个函数的开发,每一个功能点的增加, 观察一段时间
david(david) 10:27:33
你可以这样去
david(david) 10:27:41
但是我得刷新你的思想
aya(aya) 10:27:52
至于TDD,我还需要考虑
david(david) 10:27:48
因为我觉得你的这东西很时候TDD
david(david) 10:27:52
但是你抗拒TDD
aya(aya) 10:28:10
流程要执行,就一定要落实去做
david(david) 10:28:16
你看了那个视频
david(david) 10:28:20
这个不是流程问题
david(david) 10:28:25
是开发方式的问题
david(david) 10:28:30
都是在写代码而已
aya(aya) 10:28:43
一次,两次做不好,那么以后就不用推行什么开发模式了
aya(aya) 10:29:32
我怎么会抗拒TDD呢
aya(aya) 10:30:03
去年我就在问别人他们的TDD怎么执行了
aya(aya) 10:30:27
不过你得看看我们组的现状,两条老油条, 一个新人.
david(david) 10:30:30
TDD只是一个写代码的方式
david(david) 10:30:33
不是流程
david(david) 10:30:46
适合写小的单元实施
david(david) 10:30:58
如果逻辑性很强，关联度很大的大系统
david(david) 10:31:00
很难实施
aya(aya) 10:31:16
15人以内的TEAM都适合敏捷
aya(aya) 10:31:32
关联度很大的大系统也可以,要看架构师的能力
david(david) 10:31:31
要看项目类型
david(david) 10:31:38
就是测试环境啊
david(david) 10:31:47
如果你写测试代码，是要创建很多环境数据
david(david) 10:31:58
这样这个T的驱动成本太大
david(david) 10:32:13
要靠后面的综合测试工具来测试比较划算
david(david) 10:32:29
你现在这些函数，不需要太多的建立复杂的测试环境
david(david) 10:32:34
T的驱动成本很低
aya(aya) 10:33:04
这个月就是类似T的, 最终API能不能用,要看DEMO能不能.
aya(aya) 10:33:24
而DEMO又是给客户看的
aya(aya) 10:33:42
这样成本是最低了.
david(david) 10:33:41
这个是后面的测试了
david(david) 10:33:48
有很多覆盖不到的
aya(aya) 10:34:21
TDD强调的就是测试先行
aya(aya) 10:34:39
先把测试环境弄好, 再去开发
david(david) 10:34:38
不是测试环境
david(david) 10:34:44
是函数的可能的使用场景
david(david) 10:34:45
想好
aya(aya) 10:35:02
就是测试环境了嘛
aya(aya) 10:35:18
代码级别的
david(david) 10:35:14
就像我们的开发，如果开发者连用户怎么去用都不知道，做出来的东西肯定和预想有差异的
david(david) 10:36:07
你让他们写函数
david(david) 10:36:21
如果他不知道将来客户可能送什么值进去
david(david) 10:36:34
那么，他就会跳过很多逻辑的处理
david(david) 10:36:37
这个就是将来的bug
david(david) 10:36:53
这种bug是通过重现的机率很低
david(david) 10:37:05
后期的寻找成本很高
aya(aya) 10:38:56
我觉得, 我是肯定不会抗拒这种测试先行的开发的.不过需要在一个人小范围摸索,寻找适合的方式
aya(aya) 10:39:16
只有通用的开发思想,没有通用的开发模式
aya(aya) 10:39:26
软件工程没有银弹.
david(david) 10:39:31
这个是思想。实现的办法有很多
david(david) 10:39:43
junit，是JAVA下实现这样的思想的一个工具
david(david) 10:39:51
c应该也有
aya(aya) 10:40:04
这个月,先尝试用文档跟踪开发情况.其他细节我需要再好好考虑下.
david(david) 10:40:00
在项目框架中
aya(aya) 10:40:12
就是CPPUNIT嘛
david(david) 10:40:07
恩
aya(aya) 10:40:20
不过那个是C++的
david(david) 10:40:11
就是要引入这样的东西
david(david) 10:40:23
让他们像那个教学视频一样
david(david) 10:40:58
先写几句测试代码，等他的主体函数报错，再去修正他的主体函数实现测试代码的要求。
david(david) 10:41:03
通过循环迭代，完成
david(david) 10:41:15
这样以后验收，一看测试代码，也知道他做了哪些测试
david(david) 10:41:23
可以很容易推算出可能的边界问题
aya(aya) 10:42:09
这种方式我我去年尝试过的.
david(david) 10:42:09
实施是否成功，关键是T的成本
aya(aya) 10:42:19
一个项目,同时建两个
david(david) 10:42:19
就是写测试代码，不能太费功夫
aya(aya) 10:42:30
一个测试项目和一个真正的项目
aya(aya) 10:42:47
你看一个具体的场景,CSS解析器.
aya(aya) 10:43:02
CSS解析器的代码是根据规则生成的
aya(aya) 10:43:36
如果要套用TDD的方法,怎么弄呢? 没办法弄,只能是基于黑盒测试
aya(aya) 10:43:52
这种情况下,黑盒成本最低
david(david) 10:43:49
这个就是T的驱动成本太大的案例
david(david) 10:43:57
就是要做很多环境，才可以测试的
david(david) 10:44:22
所以，我刚刚纠正了你的15人内都可以
aya(aya) 10:44:42
像这个月的开发,JS API,看起来很好TDD
aya(aya) 10:44:53
但是实际的情况是怎么样的 呢?
aya(aya) 10:45:10
JS API由华仔来开发,他之前完全没有接触过JS
aya(aya) 10:45:31
所以他肯定是要在摸索中去开发
aya(aya) 10:45:43
肯定是要写了代码,才能去试试看有没有效果
aya(aya) 10:46:09
没写之前,连怎么试都不知道要怎么试
aya(aya) 10:47:01
所以软件工程难的地方在很多地方的处理都要很灵活才行,没有什么固定的模式可以套用.