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

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

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

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

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

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

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

>>平均每方法5行

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

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

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

nod

script language,30行确实不少了

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

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