现代软件工程 - 代码量等于树叶量

我 2008年在清华大学上<现代软件工程> 的时候,  和同学讨论了代码量的问题。 同学说，许多相似课程都有“代码量”的要求，就是说软件工程的项目选题如果没有到一定量的代码，就不能算合格的选题。  老师助教专门花时间分析学生的代码是否够 “量”。 我对教学没什么经验，我认为 -

软件工程课上写的软件只要解决实际问题，就至少是及格的选题。

我后来顺口胡诌了一段：

清华园有两棵果树，春天长芽，抽条，夏天开花，秋天结果。清华软件科学试验班的同学去采摘，发现果树A 的果实比果树B 的果实多很多，并且好吃。于是同学们都在果树A上采摘，并在果树A下面合影留念。 果树B 很委屈，它在秋风中摇晃树叶, 说 – 可是我的树叶量是它的三倍！清华的同学没听懂果树B 在飒飒秋风中的抱怨，背着果实走了。 冬天来了，树叶落了一地，同学们又来打扫果园，一个同学说，我k！这棵树怎么这么多叶子！

 

代码量等于树叶量，当作如是观。 

测试人员的 "量" 如何度量和评价呢?  能否用发现的 bug  的数量来看?  我在 <移山之道> 里写了一个故事,  专家也有很多论述, 例如:

http://www.kaner.com/pdfs/bugcount.pdf  

　　

I don’t have a silver bullet for personnel measurement. When I compare the quality of testers, I spend a lot of time looking at the quality of their work. I read bug reports. I
talk with them. I talk with people that they work with. I pay attention to promises they make, and whether they keep them. These don’t lend themselves to quick and easy number crunching, although you can (perhaps with difficulty) do comparative ranking of testers based on this detailed qualitative look.
If you really need a simple number to use to rank your testers, use a random number generator. It is fairer than bug counting, it probably creates less political infighting,
and it might be more accurate. 

 

很多开发人员还以自己写了多少代码为骄傲，枝叶繁茂, 是不错, 但是这些代码是否能有机地结合起来, 解决客户的问题?

项目开发中后期，Dev lead用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Dev lead很郁闷，想想自己可是没少加班啊，代码量也有，可是问题究竟出在什么方面呢？

<回答在这里>