单元测试的投入和产出

    Jerry在晚上10点打电话过来，把即将进入梦乡的我召唤回现实。除了唠唠家常外，我们自然的又谈到敏捷开发的话题上来。这次谈话终于在单元测试的问题上让他了解并认同了我的看法。对于大多数的中国的软件开发团队来说，难以实现敏捷的最重要问题是人的素质问题。一个敏捷团队要求每个成员都有较好的OOP和OOD的能力。试想你正在努力的重构有坏味道代码的同时，你的team中却有另一个新手在不断的写出新的充满坏味道的代码会是什么样的后果？这是一个难以完结的循环，不是么？单元测试能带给敏捷什么帮助是我和Jerry一直最有分歧的地方。我承认，单元测试只是软件众多测试方式中的一种。静态的看，单元测试包括其他的测试方法需要付出的成本和雇用低廉的人力进行测试的成本相比可能还高一些。但单元测试能带给我们的帮助不仅仅是在重构过程中，保证对复用代码的修改不会波及其他的调用那么简单。通过编写测试，我们可以发现代码中结构的问题并优化之。当然这建立在团队成员对OO的认识基础上，OO能力不足的程序员遇到难以测试的代码时，往往不会想着或者没有能力去将它重构为方便测试的代码。这就给我们带来一个新的管理任务，也是敏捷过程强调的一个任务，那就是培训。我们需要不断的训练我们的程序员们，使得他们能够构造出敏捷的代码。而这正是一个团队能否实现敏捷的技术关键。
    在谈话的最后，我们形成的共识是，实现敏捷是一个渐进的过程。构造一个在技术上有敏捷能力的团队有两种方法，一是用足够的钱去招聘有足够能力的程序员(大部分企业没有那么多钱)。二是将现有不符合敏捷技术要求的程序员培养为合格的敏捷工作者。而在培养的路上，单元测试正是一个很好的驱动方式和实践平台。
    最后，希望看到这篇文章的人们，在衡量单元测试成本的时候，将他可能需要投入的培训成本考虑进去并切实的实施这些培训，也将单元测试能对团队技术水平的提高这部分产出考虑进去。

说的非常好。我就经历过这样的项目。
参与的一个项目，里面有个菜鸟写的那代码，一个方法好几百行，for循环嵌套了N层，
变量名叫 a, aaa, aaaaa ，我靠，最离谱的是author注了别人的名字。后来一问才
知道COPY别人的代码时没有修改author。汗。

两个办法解决你的问题
一个是教育这个菜鸟成为一个老手
还有一个办法是开掉他 多花点钱找个老手
我个人倾向于前者，教育本身也是企业应该担负的社会责任，遗憾的是中国大多数的企业没有切实承担起这个责任。很多单位一边感叹找个牛人不容易，一边不知道培养自己企业内部有潜力的人成为牛人。

教育菜鸟成为老手，是企业应该做也必须做的事情。问题是如何培训呢？我有以下建议：公司内部成立一个新人培训的项目，菜鸟必须经过培训，在这个项目中试用并经考核合格后方可到正式的项目中工作。类似与其它行业的入职培训，没有这一关，很难保证新人的质量。

培训期间,谁出工资?谁给讲师出工资?

摘自 《质量.软件.管理--协调行动》
第19章 成长的团队 中文版P254

下面是Jensen的研究：
研究1.
当前有5个任务需要执行,这些任务的目的是建立一个30000行的军队标准的实时
执行系统。系统有一个领导者率领10个程序员创建。在这个项目之前,这些人的
平均效率是大约75行每人月。项目领导把他们分成5组，每组2个人并象征性地
发了一支铅笔。意思是让这些团队开发每一行代码并且和他的伙伴做文档记录。
结果是以每人175行每人月的速度完成了这个系统，并且错误数不到从前每人产
生的错误数量的1%。


注：根据书中提及，这项研究应该不晚于1980年。

OO和单元测试一点关系都没有。写的测试再多也不能说明你的代码是OO的。据我观察，好的OO代码，单元测试很简单，注重集成测试。相反过程式的代码，单元测试的代码会比较壮观。

培训应该随时随地的进行。不是说到会议室就着ppt讲课或者在白板上写画才叫培训。应该在发现程序员犯错的每一时间教育他们正确的做法。



怎么看你的说法自相矛盾呢？前面说OO和单元测试没哟关系，后面又说好的OO单元测试很简单？

会写并善写单元测试并不容易
如果能有老手指导就完美了
每次看到自己写得单元测试代码，感觉惨不忍睹。。。

重构