两个pair两月工作之后的rake stats

ThoughtWorks中国的一个Rails项目，两个pair两月开发之后，rake stats如图

评论

23 楼 robbin 2007-02-14  

cvu 写道

推荐Robbin用rspec on rails来写test。虽然还不太成熟，写出来的测试程序就象spec一样直观，顺便把spec一起补了。

rspec我研究过了，确实很棒，充分展示了ruby作为DSL的潜力。不过rspec现在还不支持rails的集成测试，所以不行。

对于我来说，写测试是为了保证代码质量，rails自己的集成测试可读性已经很好了，没有很强烈的需求改用rspec。说起来我最近也一直在研究rails的测试，传统的测试中后台代码的测试一般都问题不大，解决方案已经比较充分了，但是页面测试一直是一个难点。对于JSP来说，几乎是不可测试的，模板语言可测试，但是没有好的支持工具。只能求助于外在的selenium测试工具，但selenium也有自己的问题。

但rails不同，rails已经提供了非常强大而且简单的页面测试功能，特别是assert_select功能很强大，可以对response输出页面使用selector语法任意导航和断言，让页面测试变得极其简单。rails可以说是目前对于整套web应用程序测试支持最棒而且最酷的框架了。

22 楼 cvu 2007-02-14  

推荐Robbin用rspec on rails来写test。虽然还不太成熟，写出来的测试程序就象spec一样直观，顺便把spec一起补了。

21 楼 basicbest 2007-02-14  

amonlei 写道

把所有的后台开发完了，接下来开始开发页面了，这时候把web服务器启动起来，照着以前的开发模式开发页面，减少了服务器的启动时间，整体开发速度不会慢，质量又有保证了

除非是做产品的二次开发，或者类似这样已经有较成熟的领域代码的情况。否则，这样先后台再前端的顺序会出现与“整体开发速度不会慢，质量又有保证”完全相反的情况。

20 楼 amonlei 2007-02-14  

关键还是web开发方式的转变，大多数非tdd开发都是开着web服务器来开发、调试。其实这种方式属于集成测试阶段的调试方式。这方面我经过两个多月（java）的实践得出的结论：
如果采用robbin事后补的做法，会出现如下情况：
1. 程序员为了提高覆盖率而测试
2. 很多逻辑没法测试（开发时候时间紧啊，代码与环境耦合度高，没法测试）
结果测试就是东测一些，西测一些


tdd一定要在开发阶段引入，要求程序员开发每一个api前都要编写相应的测试用例文档并且通过分析员的审核（这样子制度化了程序员就养成习惯了）。接下来编写api或者编写测试用例，哪个先都没所谓了，只要保证编写的测试用例根据上面的文档来的就ok了，上面的文档最大限度反应了这个api的真是真实需求。
把所有的后台开发完了，接下来开始开发页面了，这时候把web服务器启动起来，照着以前的开发模式开发页面，减少了服务器的启动时间，整体开发速度不会慢，质量又有保证了

19 楼 charon 2007-02-08  

yuxie 写道

这个是否测试还是业务逻辑复杂度的问题。而不是项目大小的问题。
对于一些很大型的项目，在做好良好的分工后，其逻辑并不复杂，比如电信的客服等，仅仅是向BOSS发送查询和命令。项目大是大在它的数据量、并发量和可靠性要求上。这中情况实际上并不需要任何测试。因为大部分的逻辑只有几行代码而已。
但是一些所谓的小项目却相反。尤其是管理型的项目，逻辑极其bt和复杂。这时tdd简直有得天独厚的优势。它可以引导你由简单到复杂一步一步接近想得到的结果。
javaeye的经历也正是如此，一开始功能不多的时候并不需要什么test。后来随着积分计算的复杂，圈子文集等功能的加入,test就显得越来越必要。

我们可能是对"项目规模"怎么区分有分歧吧。
首先，对于软件项目，可以直接刨掉硬件投资。
其次，可以刨掉不是自己开发的，使用到的第三方框架或工具的规模(当然，前提是开发者对这些工具相对熟悉，否则学习成本也要计入)
最后，剩下的就是开发团队需要做的事情。多少人(包括团队规模和曾经出现的总人数)，多少时间来作，时间比人数有更加重要的权重。我的计算就是这样。参与的人员多，素质参差不齐，对同一问题就会有更多的不同做法，相互之间对代码的理解也会有不同；项目的时间长，人员更迭的可能性就越大，程序演化的次数也越多。
所以，前面说的较大的"数据量、并发量和可靠性"的要求，如果是开发团队自己编写代码来搞定，那是一回事情。如果只是使用其他的成熟框架，而且"大部分的逻辑只有几行代码而已"，那么这个项目从开发角度来说，本身就称不上是大的开发项目，只能说是大投资的项目.
但是，从另一方面而言，既然有相当程度的"数据量、并发量和可靠性"的要求，那么对于处理这些数据的代码，不论多简单，都会有非常严格的要求，逻辑的正确与否以及实现方式会直接影响到这些要求。而单元测试则属于预防性的措施，而且需要的不仅仅是单元级别的逻辑测试，可能还需要单元级别的性能测试.
至于功能增加引起的问题，如果新增的功能是线性无关或者相关性弱的的，我并不认为100个功能点比30个功能点会更加有test的必要性(如果仅仅从必要性出发来谈测试)。

18 楼 gigix 2007-02-07  

spritesun 写道

script language,30行确实不少了

关键在于，这30行代码是充分测试的、经过重构的、高质量的代码，这种速度是可持续、并且会随着项目进展略微提升的。

17 楼 spritesun 2007-02-07  

引用

jigsaw     3 天前

>>平均每人每天30行ruby code。

>>平均每方法5行

>>重构的结果亚，哇哈哈哈哈～～～～

>>个人感觉这是一个合理的、可持续的、相当高的生产率。

......@_@ 高 实在是相当的高

script language,30行确实不少了

16 楼 basicbest 2007-02-07  

charon 写道

猜测有一个均衡点。
项目规模小于该均衡点是，少写或不写测试的开发效率比较高。而超过这个均衡点，还是随时测试来得快。
这里面其实是一个代价和收益的问题，测试带来的收益是缓释的，如果到不了平衡阶段，测试并不能带来明显的好处。而较大规模项目，缺乏测试在后期的进一步开发和维护上都会带来不必要的开销和困扰.
对于业务/逻辑层的代码，我自己已经得了测试强迫症，虽然每次都是先写"代码-测试-代码..."的循环，而不是标准的"测试-代码-测试...".
不过，我觉得最节省的做法是，一开始不写任何测试，每发现一个错误就用测试把它固定下来并修正之。对于一次写完就自然正确的东西就不去费劲测试了.其实说到底还是个粒度和覆盖率问题。javaeye2.0如果要补测试，我觉得也可以采用这种方式，再加上对一些关键部位的重点补全。

nod

15 楼 jigsaw 2007-02-05  

>>平均每人每天30行ruby code。

>>平均每方法5行

>>重构的结果亚，哇哈哈哈哈～～～～

>>个人感觉这是一个合理的、可持续的、相当高的生产率。

......@_@ 高 实在是相当的高

14 楼 dongbin 2007-02-05  

写测试会省时间，这是我的体会。
另外，测试代码的坏味道会增加测试代码行数，造成高测试覆盖率的假相。所以不能只看1:1.4 这个比值。

13 楼 yuxie 2007-02-03  

这个是否测试还是业务逻辑复杂度的问题。而不是项目大小的问题。
对于一些很大型的项目，在做好良好的分工后，其逻辑并不复杂，比如电信的客服等，仅仅是向BOSS发送查询和命令。项目大是大在它的数据量、并发量和可靠性要求上。这中情况实际上并不需要任何测试。因为大部分的逻辑只有几行代码而已。
但是一些所谓的小项目却相反。尤其是管理型的项目，逻辑极其bt和复杂。这时tdd简直有得天独厚的优势。它可以引导你由简单到复杂一步一步接近想得到的结果。
javaeye的经历也正是如此，一开始功能不多的时候并不需要什么test。后来随着积分计算的复杂，圈子文集等功能的加入,test就显得越来越必要。

12 楼 charon 2007-02-03  

猜测有一个均衡点。
项目规模小于该均衡点是，少写或不写测试的开发效率比较高。而超过这个均衡点，还是随时测试来得快。
这里面其实是一个代价和收益的问题，测试带来的收益是缓释的，如果到不了平衡阶段，测试并不能带来明显的好处。而较大规模项目，缺乏测试在后期的进一步开发和维护上都会带来不必要的开销和困扰.
对于业务/逻辑层的代码，我自己已经得了测试强迫症，虽然每次都是先写"代码-测试-代码..."的循环，而不是标准的"测试-代码-测试...".
不过，我觉得最节省的做法是，一开始不写任何测试，每发现一个错误就用测试把它固定下来并修正之。对于一次写完就自然正确的东西就不去费劲测试了.其实说到底还是个粒度和覆盖率问题。javaeye2.0如果要补测试，我觉得也可以采用这种方式，再加上对一些关键部位的重点补全。

11 楼 basicbest 2007-02-03  

测试是重要的，但是在“实际项目中”做过测试的人，都知道测试需要选择，并不是每个东西都做上unittest。就和robbin说的一样，还是要糊口的。而且，客户要求也不同，如果客户要的是时间，适当的降低质量要求有时也是必须的。至于测试覆盖率，我个人的关注点是主要模块/组件的测试覆盖率是否达到标准。

10 楼 robbin 2007-02-02  

不对，JavaEye2.0的例子并不能证明不写test的好处。事实上JavaEye网站现在功能点实在太多了，逻辑关联性也很强，修改代码越来越小心翼翼了，我准备逐渐把test补齐。虽然我没有TDD的习惯，也不觉得非TDD不可，但是unit test一定是必要的，一个好的测试覆盖率对于软件质量是有保障的。

9 楼 yuxie 2007-02-02  

robbin 写道

两个pair两个月总共3000多行code，就是说4个人月总共写3000多行code，平均每人每天30行ruby code。

我们当时1个月1周，一个人，4000多行code，平均每人每天100多行ruby code。不是不想写test，如果把开发速度降下来，从8月份一直开发到12月底才完成，当然也可以把test写的很好，但是那样的话，我们现在可以关门大吉了。

JavaEye现在ruby code已经9200多行了，test基本没有写，实在是人力之不所及。如果我可以其他什么事情都不用做，每个月领着高薪，每天喝着咖啡写上30行ruby code，那自然test也可以写的很完美。但现在每天各种各样的事情忙都忙不过来，抛开其他因素单纯看代码，自然现在补上test比较重要，但是考虑还有那么多更加重要的糊口的事情要去做，要去跑客户，你认为待在家里写test还那么重要吗？

我觉得这个倒不是喝不喝咖啡的问题。正相反，javaeye的经验说明unit test对于网站型并不是必需的，如果不写test就能做好一个事情，那何必非得上杆子去做？我觉得很多时候我们过于强调tdd了。
不过这倒不是说unit test或者tdd不重要。毕竟对一个大众型网站来说，即使它并发量数据量非常之大，它的业务逻辑却并不复杂。tdd的作用跟本发挥不了。在我做过的几个项目里，有门户网站、有BOSS系统，也有人力资源部的招聘考核等，总的感觉就是，门户和BOSS基本上用不到TDD，只要适当的UnitTest（以db test为主）就可以了。而看上去不起眼的人力资源部的项目却是tdd大显身手的好地方，那里边充斥了众多超级不合逻辑的业务逻辑，每一个步骤都要做n多的判断和循环，不用tdd很快就会痛苦的陷入其中不能自拔。这根本不是时间紧张不紧张的问题。时间不紧也没必要回头补test。时间再紧不用test也会更浪费时间。一句话，就看需求bt不bt了。

8 楼 gigix 2007-02-02  

robbin 写道

两个pair两个月总共3000多行code，就是说4个人月总共写3000多行code，平均每人每天30行ruby code。

个人感觉这是一个合理的、可持续的、相当高的生产率。

robbin 写道

你认为待在家里写test还那么重要吗？

不同的项目有不同的情况。这两个案例加在一起证明，Rails一方面可以非常快速地开发较大规模的应用，另一方面可以延续敏捷方法严格的纪律从而保证项目在很长时间里的持续发展演进。它可以是初创企业快速抢占市场的利器，也不会因为纪律松散而让较为保守的企业遭受更多的风险。

7 楼 robbin 2007-02-02  

两个pair两个月总共3000多行code，就是说4个人月总共写3000多行code，平均每人每天30行ruby code。

我们当时1个月1周，一个人，4000多行code，平均每人每天100多行ruby code。不是不想写test，如果把开发速度降下来，从8月份一直开发到12月底才完成，当然也可以把test写的很好，但是那样的话，我们现在可以关门大吉了。

JavaEye现在ruby code已经9200多行了，test基本没有写，实在是人力之不所及。如果我可以其他什么事情都不用做，每个月领着高薪，每天喝着咖啡写上30行ruby code，那自然test也可以写的很完美。但现在每天各种各样的事情忙都忙不过来，抛开其他因素单纯看代码，自然现在补上test比较重要，但是考虑还有那么多更加重要的糊口的事情要去做，要去跑客户，你认为待在家里写test还那么重要吗？

6 楼 dennis_zane 2007-02-02  

rrtrip 写道

gigix 写道

ThoughtWorks中国的一个Rails项目，两个pair两月开发之后，rake stats如图

有吹捧嫌疑，把项目开源出来看看？

莫名其妙，这也叫有吹捧嫌疑？二话不说，伸手要代码，真真莫名其妙。

5 楼 rrtrip 2007-02-02  

gigix 写道

ThoughtWorks中国的一个Rails项目，两个pair两月开发之后，rake stats如图

有吹捧嫌疑，把项目开源出来看看？

4 楼 gigix 2007-02-02  

自我感觉比较不错的，除了1:1.4的代码／测试比之外，还有平均每方法5行的代码量
重构的结果亚，哇哈哈哈哈～～～～