本文一共有四篇，第四篇之后为何没有了呢，是因为it168当时给了张恂一个专家的虚名头衔，然后给他开了个专栏，当然，也可能有别的原因。

这是2007年，青润第三次应邀分别给it168、csdn撰写软件工程调查报告后发生的事情，相关文字不清楚为何第三篇单独被下架了，所以，考虑到内容里面还是有些价值的，就在公众号做一个重新发布。

本文当时还承蒙周爱民老哥做了一个评论，我和爱民兄接触不多，到现在大概见面四五次，但是也算惺惺相惜吧。

开篇
今天又看到了张恂的文字《青润，你的胡扯还不够吗？》  （ http://www.zhangxun.com/_templates/tmpl_AddComment.aspx?sname=QingRunReport&id=2 ），因为篇幅较短，所以，贴在下面以作响应。
“
青润，你的胡扯还不够吗？

作者 / 发帖：张恂 字数：739

煞有介事地：

" 这里还应该提到的是， RUP 中并没有告诉大家如何进行裁减 ，所以，很多人知道 RUP 而不知道如何用，更不知道该如何裁减，于是大家只能按部就班的招办 RUP 的所有过程和建议 "

我现在怀疑你有没有见过真的 RUP ？

RUP 里面有个重要的工件叫 Development Case ，具体的例子 Larman 的《 uml 和模式应用》里面就有，这本书就是一个典型的 Agile UP 和 RUP 裁减的例子。Larman 是亲自向 RUP 之父 Philippe Kruchten 学习的 RUP 。Larman 的书你都没看过，你还搞什么全程建模、 RUP 。

通常 RUP 项目一开始，项目经理和过程工程师就需要制定项目的开发计划和 Development Case ，对 RUP 进行裁减和定制。有关的文献、指南和工具像 RUP 的 Environment 科目、 Workbench 、 Method Composer 也早就有了。怎么能说 “RUP 中并没有告诉大家如何进行裁减 ” 。

你的这段话，不但是胡扯，而且还是狡辩，为自己的无知狡辩。

青润，有一点你可以放心，我认为你的报告总体上 60% 是正确的，包括对软件工程落后的现状、 RUP 在国内某些环境下实施遇到的困境和问题也比较客观，但你的感觉显然不是事实真相的全部，你的逻辑分析和结论是错误的，后面我会给出一个比较合理的分析和解释（你应该明白，先进的水平中上的企业总是在少数，真理往往掌握在少数人手里，而软件 100 强在中国庞大的软件开发队伍里面也未必都喜欢显山露水）；据我估计，你报告中大约有 40% 的论断是错误的，而且有些属于低级错误，上面这条就属其中。
”
因为我发现张恂把他的第一篇响应给删除了（就是熊节贴出来响应的那篇），关于我第二篇的响应，他开始在原文上修改，而不是重新创建篇幅。毕竟是自己的网站可以随意为之，我明白熊节为什么要作图片镜像了！
响应
我知道 RUP 的 Development Case ，张恂大概没有仔细看我文字中的内容（关于这一点我已经说过很多次，在这几篇中都有类似的提法），说实话，他 2002年给我的光环影响正在逐渐褪去，更让我感到的是，他和很多在我的 blog 上留言骂过我的人相似，都是在没有仔细阅读我的文字，就直接给了断章取义般的解释和回答。另外，出言不逊，言辞缺憾而不够缜密。
另外，关于 RUP 的裁剪，如果我们做一个调查，甚至包括 IBM 的人在内，你可以问问有多少人知道它如何使用，估计他的比例可能要远低于 0.1% ，我实在不知道国内 1000 个知道 RUP 的人中有没有一个人知道这个工具如何使用。
至少我知道在 2001 年 Rational 当年的讲师包括它的咨询人员都没有告诉我们 RUP 如何裁减，但当时也听说过一些关于 RUP 裁剪的提法，只是从来没有一个人给出过 RUP 裁剪的具体方法和操作建议。直到 RUP7.0 的文档中提供了 Process Engineer ，列在 Production & Support 的 RoleSet 里面（在 RUP2003 列在 Manager 里）。
Development Case 不是一个具体的裁剪方法，只是一个建议而已，并没有告诉大家具体如何裁剪，什么样的项目应该裁剪哪些，什么样的项目需要什么样的改变，而后者才是开发者最需要知道和了解的。
看张先生的文章和口气，他应该是知道如何裁剪使用 RUP 的，为什么却没有见到他任何一篇文字出来，指导一下国内的开发人员，至少提个建议应该是不会影响咨询顾问服务生意的！
关于全程建模
我从来没有主动宣称过我的方法是 RUP ，我说的是全程建模，我提出的概念也是全过程采用模型描述的方式进行软件开发，而并没有说从 RUP 中裁剪的内容，只是有人问到的时候，我会做前文中的解释（这里就不再重复了）。
另外全程建模也未必只有 RUP 一家， UP 的 UP 说法也未必会得到全世界的认同，所以，不要真的以为 UP 就能统一全世界，那是不太可能的，因为人的千差万别，项目的种种不同，客户的心态变化以及职位变更等等都会其所关联的项目产生影响，所以，随需应变才是解决软件项目变化的硬道理！而这些，尤其是心态变化的影响更是 UP 或者 RUP 中根本没有涉及到的内容。
这也是我从 05 年开始没有再继续看 RUP 的一个原因，虽然 Ivar05 年初来北京那趟再次强调，让大家继续读 RUP ，可是，我没有听他老人家的建议，我更希望的是在实践中摸索一套适合我这种贫下中农的软件工程理论和开发方法，而不是面面俱到的“统一开发过程”。邓小平的黑白猫理论对我的影响很大，同时，不盲目崇拜高人也是因为我的经历而给我带来的后天的强硬个性。
题外话
昨天居然见到了 O6Z 这个老鬼，我们先是互相指责了一番，我说他从哪个老鼠洞里面转出来了，他就提到了这场对话。
我们谈了半个多小时，具体内容因为涉及到一些个人偏激的看法，这里就不公布了。
呵呵， CSDN 和 JavaEye 的人应该大都了解这个老东西的。
————————————————
14年后的补充

提到UML，其实我一直认为是个好东西，几年前还和一个华为的人谈过关于模型化无bug开发的问题，就是我从2002年开始一直在做的事情。

最近腾讯的老兄弟让我帮他找一个可以入职武汉的低代码开发的技术人员，我看了一下介绍，其实内容和我一直想做的模型化开发模式已经有50%左右的相似度了，只是他们用的不是模型驱动，而是自己构建的系统驱动，或者说，是一种代码库驱动的方式。

而关于模型驱动开发，青润这19年想做的就是模型+代码库，通过拖拽的方式就可以完成几乎所有的代码，剩下的就是对代码库的升级更新，而恰恰就是这部分行程了厦门大学博士学位论文抄袭案中的关键部分。

或者说，腾讯的低代码开发，其实是跨越了模型驱动的部分，因为模型驱动这些年确实是一个低谷期，因为学习成本较高，而很多人并没有感受到它存在的实际价值和好处。

有兴趣的，愿意来武汉的朋友可以联系我，这个职位如果你合适，我可以帮助做推荐！

要求如下：

关于低代码的介绍：https://cloud.tencent.com/product/weda

腾讯云微搭低代码 WeDa 简介

腾讯云微搭低代码是高效、高性能的拖拽式低代码开发平台，向上连接前端的行业业务，向下连接云计算的海量能力，助力企业垂直上云。腾讯云微搭低代码将繁琐的底层架构和基础设施抽象化为图形界面，通过行业化模板、拖放式组件和可视化配置快速构建多端应用（小程序、H5应用、Web 应用等），免去了代码编写工作，让您能够完全专注于业务场景。腾讯云微搭低代码以云开发作为底层支撑，云原生能力将应用搭建的全链路打通，提供高度开放的开发环境，且时刻为您的应用保驾护航。