只显示主题贴

2008-08-20
全文显示

回复: 晒工资了！

shiboshen 写道长春，不到２０００K，有自杀的冲动～～ 千万别想不开.咱都一样.要坚挺地活下去..........
2008-08-19
全文显示

回复: 晒工资了！

呵呵.工作多长时间不想说.不是没的说.是工资太低不好意思说东北 1800(不用交税)-219保险=1581
2008-08-15
全文显示

回复: 二． 测试的粒度，我们到底应该把粒度控制到多细？

amonlei 写道单元测试： 看代码覆盖率 集成测试：看业务操作覆盖率 不能一概而论，这两点我们处理的很理想，有兴趣可以讨论讨论好.我现在的问题就是鼓励大家去写测试但似乎没有什么效果.因为是老项目.以前都没有什么测试代码的.大家也都习惯了没有测试的日子.表现就是代码覆盖率是根本不动.又不好逼着他们做测试.闲的时候都是去上网聊天.没见人主动做测试,而且给我找出N多理由.
2008-08-13
全文显示

回复: 如何推广前端单元测试

xidaboy 写道做单元测试肯定是做比不做好 人员抵触主要还是时间安排上是不是有问题啊 我们做的时候比如 xx=xx,就是开发 yy=yy,就是单体测试 zz=zz,就是结合测试 没什么抵触,如果你既不安排时间,又让大家做,那当然了,不抵触才怪很多时候是他们有时间也不愿意去写测试.我最近也遇到同样的问题.在你这里等看有没有解决方案.其实只要涉及到人的问题都不容易解决.
2008-08-13
全文显示

回复: 结对编程简介

kimmking 写道没有绝对的真理 我们只能自己摸索自己的路子 的确.找到适合自己的方法.这些都是不推荐强迫的.
2008-08-13
全文显示

回复: 结对编程简介

roottag 写道人不是机器， 编程需要激情， 软件需要创造力， pair programming太理想了，让我联想到鬼子和台湾人的血汗工厂。 看看google，看看微软吧 其实我们是花了两个小时的时间做了四个小时的事情.剩下的时间其实可以自己支配.我相信没有人可以一天都在pair(这样才是压榨).如果有相信也没有什么效果.只有两个人都精神非常专注(我相信精力集中更有可能创造好的软件)才能体验到pair的好处. pair可以让我们更有激情,更多的头脑风暴.有的时候甚至可以让你感觉到你的打字速度跟不上你的思想. 至于MS和Google我不想多说什么.至少我还没有能力去那种地方.当有能力去了再 ...
2008-08-13
全文显示

回复: “Scrum and XP from the Trenches”中文版正式发布

很不错的书.我一连读了两遍.第三章尤其经典,第五章也不错
2008-08-04
全文显示

回复: 二． 测试的粒度，我们到底应该把粒度控制到多细？

抛出异常的爱 写道 勇气之类的是个虚词。。。。。 代码评审要时时刻刻作。。。。 每个svn记录后都要有人查看一次。。。 不然重构有什么意义？ 是不是虚词这个事情我不想讨论。至少我不喜欢去碰那些没有测试的代码。 代码评审我们是有的。我发这个帖子的意思是想问问大家在一个已经进行了几年的项目中，如何推广测试，如何让他们接受测试。而上面正是我现在存在的问题。数据不稳定如何进行测试？测试由浅入深。并且想请教下大家是如何在团队中推广测试的。而且我现在面临比较大的困难是，同志们通常很不习惯写测试。
2008-08-02
全文显示

回复: 二． 测试的粒度，我们到底应该把粒度控制到多细？

leton2008 写道 单元测试更关注开发者完成的单一主体功能的测试。 部分集成测试则关注功能完整性和正确性的一种测试。 难道单元测试不需要关注单一功能的正确性和完整性？单元测试的正确性是什么评定的？是否是某方法返回的结果呢？ 比如这样一个方法。他查询数据库，并统计当前注册人数。而这个人数是不断变化的。我们的测试应该如何写呢？
2008-08-02
全文显示

回复: 二． 测试的粒度，我们到底应该把粒度控制到多细？

gurudk 写道yh_private 写道抛出异常的爱 写道主要看需求的写法 如果这回写错了， 下回写细一点。 必竟TDD是以不断变化为前题的。 哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。 换个思路，代码评审对编码质量的提高更好。 代码评审如何给我们重构时带来勇气呢？难道每次重构就要把所有相关的代码全部审一遍，更何况表结构这样的变更需要非常细心的评审，实施起来恐怕比较难？
yh_private
搜索本博客
最近加入圈子
存档
最新评论