[软件工程]关于调查报告的响应和看到张恂的批评

Posted 2021-06-30 青润

前文发布后，有朋友评价说，张恂，他很熟，赵括式的人物。嗯，看来我需要再把我那篇关于赵括的文章转达一下了。我知道他的意思，大家应该也能听懂。不过，赵括的场景还真的未必，有些需要更多的深思一下。先回到正文吧。

本文最早完成于2007年，是在张恂的言辞逼迫下写出来的，明确说，此前对张恂还略有尊重，此后，则尊重不在。当时张恂在自己的网站上对自己的介绍好像是中国最牛的XXXX，现在好像这几个字已经不在了，也许是年龄大了一些，稍微平和了一些。然后，就看到他给自己挂了一个头衔umlgreatchina的头衔，与潘加宇umlchina对应的头衔指责老潘同志只是业余uml中段的水平。唉，还是到处骂人，不务实呀。

不过，看到他还在推uml，有些欣慰，虽然我也没有放弃uml，但是这十多年我确实没有继续推进什么，而是在等待时机，潜伏以待。而这位张某人的项目经历好像还是二十年前的那些，确实感觉这位先生（比我大四岁左右）没什么长进。

下面的内容是原文复制，访问量六千多人次，帮朋友们了解这个事情的相关经历，本文其实是第一篇，前面发表的是第三篇，此外还有两篇短文，也许可能不会转过来。

本文当时的评论比较多，可以看一下：

互联网是有记忆的，永不消逝的。

青润曾经说过，青润保存的数据是从2002年到现在都可查的，因为2002年一块硬盘的损坏，否则，从1997年开始到现在的数据，青润都有备份，那时候比较穷，实在买不起太多的硬盘做备份。

原文：

引言

今天我在参加csdn的英雄大会，上午听完了ibm一位老大的讲话后睡了一小觉，中午出来吃饭下电梯的时候遇到了熊节，打了招呼，他突然转过头来对我说，今天有人骂我了，他帮我做了个回复。这弄得我一头雾水，骂我了？谁？我当时以为还是关于那个大四学生的那篇文字上又有某位高人送了我一顶什么样的高帽子呢（曾经有人给了我一顶帽子，名为：民族败类——这里与大家共勉）。

于是，下午找了个时间，问了熊节一下，他告诉我说，是张恂，关于调查报告的事情。我心里一下子明白了一些，于是决定上网后直接来看看。

知道23点才回到宾馆，上来就看了所有相关的文字 和张 先生的评论。

个人认为，张恂的有些评论还是有些道理的，但是，部分评论的内容和意见我的确不敢苟同。

这里应该说明一下，我一直认为 张 先生是我的偶像，一直认为 张 先生的软件工程知识和水平远在我之上。我blog上增加的第一个目前也是唯一一个专家的网站就是 张 先生的，所有的朋友都可以看到这一点。在他之前增加的那个连接不算是专家网站，因为那是由于2004年9月csdn软工版内发生的一次大震动而看到的一篇关于评价微软mvp的文章连接。

我觉得，张恂之所以发表出这样的评论，应该是和他对这篇文章的数据来源不了解相关的，这些我将在后文中进行我的观点的表达。

出于对张恂的尊敬和熊节帮助的感谢，我必须写下此文，进行一下我个人的观点陈述。
文章来源
报告原始文章

中国软件开发工具应用状况分析（ 2007-01-29 ）http://tech.it168.com/m/p/2007-01-29/200701290911953.shtml
中国软件质量管理和测试工具的应用状况分析（ 2007-01-30 ）http://tech.it168.com/m/p/2007-01-30/200701300922046.shtml
中国软件项目开发管理体系建立状况分析（ 2007-1-23 ）http://tech.it168.com/m/a/2007-01-23/200701230933790.shtml
我blog上的全文连接：https://blog.csdn.net/qingrun/article/details/1541890 
张恂 的评论文章

原文连接
http://www.zhangxun.com/_templates/tmpl_AddComment.aspx?sname=news&id=35

评 CSDN 软件工程大大大版主青润的《中国软件工程技术应用调查报告》

图片镜像（熊节收藏）
http://www.flickr.com/photo_zoom.gne?id=441650572&size=l
熊节的回应
http://blog.csdn.net/gigix/archive/2007/04/01/1548368.aspx
这是个什么硕士？

 
一点附加说明
本人只是本科学历，不敢和硕士乃至博士学历的朋友们相比，加上本人的原专业为材料物理方向，更非计算机相关专业出身，有幸混到现在，得到国内软件行业内同行的少量认可，才敢发表一些自己的言词和观点。
关于本人与csdn软工/管理板块的关系是大家都知道的，但是，我从来不认为这个版主就如何如何的大，2002年以前在csdn软工/管理板块上的朋友大都很少上来的，我留下来的原因是因为我对csdn的一些留恋，不希望看到自己曾经的论坛版面变质，因此，才不惜花费小量时间留下来，对这个版面进行着铁腕的管理（我可能是csdn版主中封杀帐号最多的了，注意，不是最多的一个，而是最多）。也算是在csdn留下我期望（这种期望未必是别人的期望，不过，人都有自私的一面，我也不例外，所以，大家就不要针对这一点来骂我了）的一片净土！
本文中所有观点都是我个人观点的体现，我的言行自己负责，也从不受人指使，或者被强迫做事。
 
我的解释
文章成因

这篇文章是应熊建国老哥的邀请撰写的，文中表达了我个人的观点和一些看法。
由于文字涉及到itpub调研的大量数据和信息，因此，我对这个数据的真实性并不质疑，虽然对其中参与人员的素质和级别做过一些质疑性文字（大家应该可以从文中看到这一观点），但是，基于对统计数字的尊重，所以，我只能在相应的数字基础上表达出我的疑问（部分疑问得到了 张 先生的认可）。
另外，文中表达了我对RUP和XP的一些个人观点，这些观点被 张 先生斥之为：胡扯！瞎扯！这相关的文字我必须做出解释，同时，我认为 张 先生的这个评论与其地位和形象不一致。您可以说我的看法的错误，但是，只用这样的两个字来批评我的观点和看法，似乎是不太妥当的！关于相关被指责的内容，我下面将一条一条做出回复。
逐条回复
第一条：
“调查显示，目前企业中采用轻量级过程XP框架的战友42.5%，重量级软件过程RUP框架的战友17.7%，采用微软MSF框架的有14.6%，而采用自定义过程管理框架的战友20.3%，目前仍然没有采用任何过程管理框架的只有微小的4.9%的比例。”
采用 XP 的居然占到这么高的比例，确是一个意外。就算在北美，这么高的比例也达不到吧。在此，顺便向“中国 XP 第一人”—— 伟大的熊节、熊透明、熊名家致以最崇高的敬意，您的努力终于获得了巨大回报，实在是功不可没啊！
不知道“采用 XP”与“采用 XP 框架”是否是一回事。这项数据很可疑。不错，青润确实也注意到了这个情况，他关于这一矛盾现象的解释也比较合理。真实的情况恐怕是：“国内测试能够将 XP 中的测试实践做到相对比较好的程度的组织的比例也就只有 2% 左右”，窃以为，这个 2% 大概就是国内真正采用了 XP 而且会用 XP 组织的上限（悲观的估计）。

不知道这次调查的样本情况如何。搞这样的调查我觉得是有意义的，但关键在于是否具有科学性、专业性、权威性和公正性。类似的调查最好由中国软件行业协会或信产部的有关部门组织来做。如果仅仅是一次“导购性”的商业调查或者单纯由 IT168&ITPub 的网友们（分布情况如何，是否具有统计意义，有代表性吗？）来投票，这样的调查根本不能代表中国也不应冠以“中国”前缀，好大的动静。

我虽然也认为部分参与调查人员的情况可能并不能合理比例的覆盖中国软件行业各个层面的技术和管理人员，但是，我觉得尊重数据，尤其是尊重统计数据是一个比较可信的行为。所以，我在文中只是通过多个相关统计数字之间的差异和互相的支持关联信息对一些人员的情况进行了相对合理的推测和分析。关于it168&itpub是否能够代表中国，或者冠以中国的前缀，这个无论从商业的角度还是宣传的角度来看，也并不是什么原则性的错误。

如果it168&itpub将这个数据拿给国家统计局作为标准数据来发布的话，那这里就肯定会存在问题，而现在只是it168&itpub自身在自己网站上作的发布，似乎不必过于大惊小怪。

中国还有更多不讲道理的企业在做着大量更为过分的事情，如果真的要批评，那我觉得 张 先生大可以把目标指向这些企业，比如：我曾经工作过的托普，还有很多目前仍然或者的类似托普的公司。我个人认为这样的评价可能才是更有意义，更需要投入精力的事情。

 
第二条：

“关于RUP相关数据的评论：从软件企业的开发过程和实践来看，完全采用RUP的过程框架进行开发在中国国内是不太现实的，因为RUP过程本身的复杂度和管理上的重量是国内从大型企业到小型企业都无法承受的。” —— 这段明显是胡扯！

关于这段文字是不是胡扯，我有一个个人看法需要说明。

我曾经亲身参与过全程应用RUP的项目实施，在这个项目中感觉到了uml的好处，后来也主动的推动了uml在项目中的实施，在国内的工程项目中经历了大到合同额接近两千万涉及到11个省级电信公司和电信集团公司的项目小到几十人天的项目几十个。

从我对国内软件企业的了解和对客户方耐心与耐性的认识，以及我应用RUP的经验分析认为：应用RUP等重量级过程模型的确可以在一定程度上提高软件质量，但是，要在开发周期上，尤其是第一次交付前的开发周期上比原始的开发过程相对有所延长（大概要延长20%到30%），而这个时间的延长所带来的第一次交付的成本也相应提高（对比时间周期的延长，这个提高也在30%左右，这两个都是估计数字，请勿追究其准确性）。

由于曾经的国内软件企业的混乱管理和信誉度低，使得目前的用户更希望的模式是：合同签署，软件就交付，合同就付款。而这个时间的延长，会让用户感觉到他们始终没有看到软件产品，而产生相应的担心和对开发商的不信任。几乎所有的合同都会因为用户方的要求而定下一个不合理的交付时间。

所以，基于这种分析，我认为我的这段看法不是胡扯，而是由我的项目经验，乃至很多同行第一线的软件开发者的经验积累而得到的，我相信只要是在工程软件项目第一线参与过开发的技术人员基本上都会有同样的观点。

 
第三条：

“而XP的过程由于其先天的特征，要求企业内必须有技术水平绝对高的架构师的存在，而从中国的软件开发历程来看，中国国内目前还没有开发经验20年以上的软件技术人员存在，加上软件技术本身的变革和飞跃，基本上可以认为国内目前还没有真正培养出自己的软件架构师的时间，所以，从这一点来看，完全的XP实施就是不现实的事情，但是部分的采用XP框架进行实施是有其应用环境的。” —— 瞎扯

这段话，说我瞎扯，我就不是很明白了，怎么才是瞎扯，而我记得在XP的要求中就有一项关于架构师的内容，这是必要条件之一。

而国内技术人员的经验，大都不长， 张 先生自己所言也只有十多年。

说实话，我一直认为十多年的经验是不够用的，十多年的经验你可能成为理论高手，而未必是一个实践高手。

我是从一线的coding做起的程序员，虽然也有人认为我后来代码写的少了，其实一直到现在，几乎每个月我都会写代码，我个人认为如果哪天我真的不再写代码了，我也就离开了一线，也就不能再评价具体的编程技术以及相关的技术内容了。

不写代码的人，绝对不是程序员！
而程序员，才是软件业的核心领导力量！
——这是我一直以来的观点！

国内的现状大家是有目共睹的，我只是不太 明白张 先生说我瞎扯的原因和具体的批评点。

如果说这个批评是针对水平绝对高的架构师存在这句话，那么我认为我没有说错，中国大陆的确存在这个问题，而且这是个很严重的现实问题！我们的核心程序员大都是九十年代培养起来的，而九十年代初期就开始写代码的技术人员几乎都走向了管理层，或者离开了软件业。这也是因为软件业所有的技术变革都是国外企业主导的，这种主导使得国内的技术人员在没有来得及适应新技术的情况下，就被迫接受新技术的改造和带来的压力！我们这些人常常是疲于奔命呀！

一项技术的主导国家的技术人员是有时间适应的，因为他们可以第一个看到技术的变革苗头，而为此做好一些相应的准备，而在我们国家，这些变革的推动往往是排山倒海式的打来的，我们只有仓促应战，仓促学习，仓促掌握，受制于人！我们没有办法在这变革之前就看到一些苗头，而提前进行准备（当然，这种现象会逐渐减少，因为随着国际交流的扩大，在国内也能收到国际上的新技术苗头的影响了，但是在上世纪九十年代这种变革就是突如其来的，让人无法或者没有时间来适应，而不得不选择退出或者改变）。

当然，有人会说，掌握一门语言就如何如何，不过，因为技术变革的影响不仅仅是语言的问题，否则，也就不会有borland目前濒危的境况而在去年选择出售他的开发工具部门未果的情况下将开发工具部门独立成一家独立的公司而存在。
 
第四条：

“调查显示，国内的开发者有76.8%的人的工作内容中涉及到项目管理工作，而只有23.2%的人不涉及到项目管理工作。图表 6 开发者在工作涉及项目管理工作的状况” —— 又一项离奇的数据

关于这是不是离奇数据，我前面做过响应，这里就不再赘述了。
 
第五条：

“Rational两个工具居然占有了百分之三十左右的比例，这说明白盒测试方面其他公司所开发的工具的确是相对较弱的。白盒测试与黑盒测试不同，其技术难度和复杂度都要比黑盒测试要高很多。可以这样说，有能力开发白盒测试工具的厂商肯定能够推出自己的黑盒测试工具，而相反，则很难。” —— 什么逻辑？

说到白盒测试和黑合测试的问题，我觉得只要有测试常识的人都会知道，黑盒测试的操作过程相对简单，虽然修改过程未必简单，但是，黑盒测试只要给有测试知识和一定经验的人就可以完成，因为他不需要分析代码结构和代码内部的流程以及相关的分支覆盖等行为。

而白盒测试则不然，他所需要的测试人员必须有相应的编码知识，他们必须进行黑盒测试以外更具有难度的代码分析以及分支覆盖方面的测试，这些对测试人员的要求也相对较高，我相信这一点， 张 先生也不会否认吧？

如果是这样，那么，我上面这段话应该是没有逻辑问题的。

还希望 张 先生多多指教，我这里的逻辑问题存在在哪里？
 
第六条：

“我们可以看到有接近40%的开发者和开发团队没有使用过自动测试工具，这并不是很令人惊讶的事情，但是却有接近四分之一的开发者和开发团队没有听说过自动测试工具，这就很惊人了。没有用过，可能是因为自己周边没有人会使用，或者地域偏僻，或者没有学习到，但没有听说过，这个差别就说明中国国内软件企业和开发者在测试领域缺乏认知程度，同样的比例数在白盒测试上也是存在的。” —— 这让我怀疑样本数据的有效性

样本数据有效性的问题我前面做过响应，这里就不再赘述了。
 
第七条：

“ ... 用自动化测试工具进行测试的只有29.2%。图表 20 开发者团队采用的软件测试方式的分布状况” —— 前面提到“采用 XP 框架的”占 43%，而用自动化测试工具的只有 30%，那么请问，这中间的 13% 算什么？会用 XP，却不会用自动化测试工具（如 xUnit）？显然这次调查的样本是有问题的，调查的组织和问题设置好像也存在缺陷。

 

关于这次调查的问题设置，我曾经和熊建国老哥提过我的看法，我也认为部分问题的答案设置不合理，老哥当时给我的答复是已经这样了，希望我能写下去，把我的观点和看法写出来就行了。
关于用XP是否会用自动化测试工具，我认为这不是必然的联系，会用与否，使用XP中的那些关键实践，这都是一家公司/团队可以选择的，任何一家公司/团队都可以根据自己的特点或者项目特点选择在某个阶段采用某种过程或者开发方法来进行，而在另一个阶段有计划的选择另外一种过程或者开发方法。
会用与是否全部采用之间是有差别的，所以，我不认为这两个数据间相差的13%有什么严重的过错。
 
第八条：

“看出国内还有40%（这个40%的比例可以从后续的几张图表中得到数据支持）以上的企业和组织根本没有认同测试，他们仍然处在最原始的软件开发状态下生存着。” —— 我看这 40% （数量惊人）的原始人类，不但是傻冒，而且是赌徒，他们不是再做软件，而是在耍软件，真是酷毙 le。

这个观点我也赞成，国内的确有着40%的企业是原始人类，是傻冒，是赌徒，他们不是做软件的，而是耍软件的，他们不仅仅是酷毙了，而甚至有可能是卑鄙无耻的企业。

他们的软件只是为了骗人或者糊弄用户，他们的员工也很可怜，每天应对这自己不应该应对的事情和问题，或者为别人擦屁股，或者做着劳而无功的事情，或者每天被骂，而只能领取着可怜的，微不足道的薪水为了生存而卑躬屈膝在这些有着背景和关系的老板的公司里面卖命。

这个数据也让我感到很悲哀！我没有办法，我也没有力量，我只能尽我的可能在我认识的企业和人群中为程序员争取和呐喊，获取一些支持和同情，让大家能够尽可能的快乐一些的工作和生活。

以上内容是针对着40%作的评价，大家看问题的时候尽量全面一些，而不要局限于这点提出中国软件业无可救药的说法，那就不是我的本意了。
 
第九条：

“每小时构建的2.1%与前面的完全采用迭代化开发的6.4%的比例是何其得接近，但是从这里我们可以看到中国软件业规范化的希望。而从52.6%的每周构建和25.2%的每天构建中，我们看到的更多的是担忧和国内软件开发状态的混乱” —— 6% 是 2% 的 3 倍，近乎 300%，怎么叫“何其得接近”?

这个数据，我现在也认为是何其的接近，这个比例我不是从6%还是2%来看待的，我是从这100份中只有6份和2份中进行统计考虑的。
由于人的偏差和认识的偏差，6.4%的完全迭代化开发的比例并不代表这些人必须使用每小时构建的方式来进行软件构建。如果 张 先生认为我这个观点有问题，我想可以就这个问题我们做一些试验或者测试来验证，似乎更为合适。
无论是6%还是2%，他们都只有整个100份中的很微小的部分，他们都是不是主导或者大部分，从这里来定义，我认为这两者就是何其得接近！
 
一点中结
这里不是总结，而只是中结，因为我相信这篇文字不会到这里就截止了， 张 先生应该也会为此做出后续的响应文章。我也同样期待着。

张 先生曾经的文章给了我很深的影响，我在此表示对 张 先生的尊敬！但是，尊敬，并不代表我就必须同意 和支持张 先生的看法！因为，我至少是一个有个性有主见的程序员！

至此，待后续文，谢谢！
————————————————