Appearance
第5章 警惕和揭示伪创新
如果人脑只需要编辑 UML 模型就可以实现系统，不需要编辑 Java、 C#等文字形式代码，那么 UML 模型就相当于“源代码”。这是目前可 以期待的，也是图 1-27 中向上的箭头目前能到达的。
图 1-27 中的“鸿沟”则表示目前还非常需要人脑（建模人员的大 脑）去解决的部分，后面在谈到人工智能对建模工作流的帮助时还会详 细讲解。
因此，不存在什么“无代码” 、“低代码”，人最终需要编辑的那个 东西就是“代码”。
★很多（15+）年前，一位 CTO 向我展示他们的软件，说不用编 码就可以为不同的客户定制。我问他怎么做到的，回答“只需要改配置 文件里面的各种信息就行！ ”。其实那个配置文件就是一种“代码”。
总之，关于“源代码是设计” ，不管是 Jack Reeves，还是后来花 心思包装的 Robert C. Martin，认识都是不够严谨的，正如 1.2.4.1 思 维颠倒所说的，主要问题出在对“设计”的认识上。
1.5 警惕和揭秘伪创新 初中数学里要学习全等三角形、相似三角形、SSS、SAS……，到了 高中以后学了正弦定理、余弦定理等解三角形的知识……就不会再回去 用初中的方法解题了。
但是，不是所有人都能学会高中的知识，比如说张三。
张三可能会这样解释：
70
“我这个人能力比较弱，只能掌握全等三角形、相似三角形的方法。”
这样的说法没有问题。
张三还可能会这样解释：
“这个题目比较简单，用全等三角形、相似三角形的方法做足够了， 而且这样更方便广大人民群众理解。”
这样的说法也可以。不过，竞争对手不是傻子，市场中哪里有什么 "简单题目"！能带来利润的题目都很复杂。
但是，张三如果这样说：
“全等三角形、相似三角形的知识比高中三角函数的知识更深刻。”
这是自欺欺人。
更要警惕的是，有一个李四，也许和张三一样没有掌握高中方法， 也许掌握了高中方法但是为了忽悠张三们，偷偷把"全等三角形"改名为 "叠合三角形"，然后和张三宣传：
“我发明了"叠合三角形"新方法，比高中的三角函数有用，三角函 数过时了。”
这就是可恶了。
前文已经提到过伪创新，此处，我们再来详细谈一谈。
1.5.1 你情我愿的伪创新
一些开发团队的工作实际上是在装模作样，浪费时间在那里废话刷
71
工作量。在“猪都会飞”的时期，特别是在开发团队的能力不是关键竞 争要素的领域，废话刷工作量的危害没那么明显。
而开发团队为了突出自己的贡献，想表明所在组织取得的成功来源 于本团队超人一等的能力和努力，迫切需要拉上某些“方法”作为面子 和证据。
于是，国外国内就有人炮制出各种投资少，见效快，产量大、门槛 低、仪式感十足的伪创新，组成圈子向开发团队宣传。
开发团队一接触，欢天喜地连称“受用”，更加心安理得地假装努 力，骗客户，骗领导，骗自己。
前些年，伪创新以“敏捷”为名，近年来，伪创新以“DDD（领 域驱动设计）”为名。细心观察可以发现，背后的主要推手是同一批人。
1.5.2 伪创新的特点
1.5.2.1 不学有术
严谨而系统化地研究某个领域中前人的成果，清楚前人曾经想过什 么，做过什么，哪些成功了，哪些失败了，才能提出真正的问题并解决 问题——这是真正的创新。
伪创新圈子的“创新”却来得非常容易。
他们不去认真研究前人的成果，而是基于自己碎片化的阅读和经验， 把一些朦胧感悟写出来，然后造一个新词来命名，就得到“创新”了。
72
★有的网红甚至是这样“创新”的：我和公司同事某某（也是网红） 讨论了什么什么，就悟到了某某创新。
在伪创新圈子的文字里，常会见到“我突然想到”、“我发现”、 “我悟到了”等字眼。
如果仅仅是发表自己的体会或感悟，即使内容是错误的，也是个人 自由。伪创新圈子的问题在于：他们硬要把自己的体会包装成“创新”。
图 1-28 体会和创新的区别
天下没有免费的午餐！“不学”却“有术”的伪创新，它的内容符 合以下特点之一：
（1）错误
不管是过去的开发团队，还是现在的开发团队，用上了不但没用反 而有害。错误的内容可谓是“百花齐放”，什么样的都有。
（2）过时
73
悟出来的内容，其实之前已经存在而且在一定时期内发挥了作用， 但现在已经被更好的知识取代。
例如，某 DDD 实践者分享了自己创造的架构表示法，仔细一看， 不就是 1970 年代的数据流图吗？现在在需要画数据流图的地方，使用 UML 或 SysML 活动图是更好的选择。
（3）拙劣的模仿
例如，某发明家急于“创新”，模仿现在仍在发挥作用的方法学自 己搞了一套，只不过各种名称换成了自己的“造词”。由于不下功夫学 习，囫囵吞枣，“创新”的“方法学”比起现有的成熟方法学来，到处 是倒退和漏洞。
学霸做了一份试卷，比较难，估计拿不到满分。学渣自告奋勇，硬 是要帮学霸改一下以提高分数，你猜，会是什么结果。该掌握的知识没 有掌握，就硬着头皮“创新”，后果可想而知。
上面所说的不只是符合软件开发的伪创新，网络上的各种“数学民 科”、“物理民科”的“数学创新”、“物理创新”也是非常符合的。
如果这些“民科”能花时间去认真学习大学（本来想说高中，但听 说中学要求的学习深度在逐年下降）的数学和物理——就当是卧底， 带着批判和找茬的目的去学——学习到能独立把大部分习题做对的程 度。
如果他们真的能做到这一步，估计也就不会再相信之前自己瞎掰的 那些东西了。
74
可是有多少“民科”会这样去做呢？如果他有如此认真学习的兴 趣和毅力，之前他也不会“不学有术”地频频“创新”了。
我也曾经和软件开发的伪创新圈子说过多次，就算是带着批判和找 茬的目的，把我的书看一看，把我出的几百道题做对了。
同上，要是真的把题做对了，他也就不会再去相信那些伪创新了， 甚至会为曾经相信那些东西而羞愧。
可惜，没有人能做到。有的人看两页书，题也不做，就啪啪啪发一 堆感悟——然后，一直停留在那里。
最后要说明一下：
“民科”说的是做事的态度和方法，并不绑定具体身份——例如 定义官方研究机构之外的研究者一律为“民科”。
不少真正的创新来自企业。特别是 IT 业，一些创新甚至来自非正 式团体或个人。不过，官方研究机构的人员筛选，使得伪创新的概率会 小一些，至少知道写东西之前要先做研究。
而企业特别是互联网企业在“猪都会飞”的膨胀期，吸纳了各种各 样没有严谨态度的人员——所以，大家可以看到一些头部互联网公司 会加入很多伪创新的推波助澜中，特别是员工喜欢到处“布道”的互联 网公司。
当然，也有著名科学家年轻时真正在研究科学，进入老年之后大脑 退化，不能也不愿沿着科学的道路继续探索，同时又面临死亡的无解难 题，于是转为宣传宗教甚至迷信。
75
1.5.2.2 造词
如果人们得知一个东西曾经存在过，那么当这个东西再次被拿出来 宣传时，人们会对宣传持有较多的理性，“这东西如果真的这么厉害， 那之前怎么……”，宣传的人也会收敛，不至于那么夸张。如果起一个 新名字，就会给人一种“全新”的感觉，人们可能就会给一个机会，毕 竟是“新”的，没准人家真的有这么牛呢。
伪创新圈子很擅长造词，恨不得每个用词都能当演讲题目。
（1）造词手段可以是换词，相当于 X→Y。
例如，把“术语表（Glossary）”换成“通用语言（Ubiquitous Language）” 。
换词是比较粗暴的，下面的做法就比较温和。
（2）造词手段可以是微调，相当于 mX→nX。
微调可以是加减数量，例如，把“六边形架构”的边数减 2，得到 “四边形架构” 。
微调可以是换某个字，例如，把“彩色建模”改成“四色建模” 。
（3）造词手段可以是加前缀，而且可以加不止一个，相当于 X→ AX、ABX……。
例如，在“愿景”前面加前缀“领域”，得到“领域愿景” ；在“事 件”前面加前缀“领域” ，得到“领域事件” ；在“需求”前面加前缀“业 务”，得到“业务需求” ；在“需求”前面加前缀“用户”，得到“用户 需求” 。 76
图 1-29 是知乎上的一篇阅读量还比较大的 DDD（领域驱动设计） 文章，先不说“领域模型……反映需求的本质”的说法是错误的，光是 看在“需求”前面累计叠加了三个前缀得到的“领域内用户业务需求” 就叹为观止了。
图 1-29 知乎上的一篇关于领域驱动设计的文章
（4）造词手段可以是加后缀，而且可以加不止一个，相当于 X→ XA、XAB……。
例如，在“功能”后面加后缀“架构”，得到“功能架构” ；在“功 能”后面加后缀“设计”，得到“功能设计”。当然，还可以连起来— —“功能架构设计” 。
把前缀后缀都利用起来，可以得到“领域用户业务需求功能架构设 计”。
显然，在加各种前缀后缀的时候，“发明家”并不真正了解原词和 77
前缀后缀的真正含义，只是为了强调自己对所加前缀后缀的重视—— 我非常重视领域、业务、用户、架构、设计。
还有一种前缀后缀值得特别警惕。
伪创新圈子喜欢用当下的热词作为前缀和后缀，例如前些年的“敏 捷”、“精益”，还有现在的“数智化” 、“人工智能”等，因为这些热词 给了他们造词的理由——××时代都到了，不得整一套新方法啊？
有心的读者可以观察造词圈子的文章，看看有没有类似以下模式的 表达：
在[某热词]的时代，[某伪创新]提出[某新词]
在[某热词]的形势下，[某伪创新]提出[某新词]
这些热词的作用类似于手机壳。手机还是那个手机，换了壳之后， 就摇身一变为“更新更好”的手机。
1.5.2.3 用口号代替方法
选择一个让人无法反驳的口号，通过圈子的力量宣传这个口号，占 据舆论高地。
然后，再慢慢用这个口号来选择性地包装一些已有的方法，成为圈 子的“创新” 。
口号可以是一个褒义词，例如，“敏捷（agile） ”。
、
★近年圈子使用的褒义词还有“精益”“现代” 、“活”等（欢迎读 者补充更多资料）。
78
有一次我评点客户开发人员提交的工件，顺便批评了他们团队中一 些打着“敏捷”旗号的粗陋做法。然后，一位女生天真无邪地问我， “老 师，希望敏捷一些难道不好吗？”——此处提到“女生” ，没有歧视的 意思，只是如果让我想个例子，我印象最深的就是这个。
我还能怎么说！ “敏捷”这个词本身就是褒义的。它占领了正能量 高地，让人无法反对。
在陈述事实的基础上，才可能有合理的讨论。像下表中这些，都是 陈述事实：
面向对象 面向过程
命令式 函数式
深度优先 广度优先
状态图 活动图
民营企业 国有企业
图 1-30 陈述事实的用词
面向过程好还是面向对象好？或者什么情况下面向过程会好一点， 什么情况下面向对象会好一点？民营企业好还是国有企业好？或者什 么行业适合民营企业，什么行业适合国有企业？或者什么发展阶段优先 发展哪一个？
这些都可以讨论。
79
“敏捷”就不一样了，它直接上了一个褒义词。这个褒义词的对面 是什么？迟缓？笨拙？你还怎么讨论呢？它已经立于不败之地了。
可能有的人会说，“敏捷”的对面是“瀑布”啊！
“瀑布”对面其实是“迭代”、“增量”这样阐述具体做法的词— —这也是本来已经在用的词，但“敏捷”把它们抹掉（后面的段落“割 裂历史和封闭引用”还会详述），直接上一个褒义词来降维打击。
在“敏捷”口号之前，那些后来被称为“敏捷”的过程，叫做“轻 量（Lightweight）”过程。
“轻量”虽然也是一个形容词，但还是比较中性的。就像我们说一 个公司是小公司，从员工数量、注册资金或营业额上看，事实确实如此， 但如果说公司是“敏捷公司” ，味道就大不相同。也许是因为“轻量” 的煽动性不够，圈子选择了“敏捷（agile） ”。
”并非软件业特定圈子首先使用。1991 年，制
★“敏捷（agile） 造业就有“敏捷制造” 、“敏捷企业”的口号，如图 1-31。不知道软件 业圈子是有意借鉴还是不谋而合。
80
图 1-31 1991 年已经有“敏捷”口号
口号喊出来并大肆宣传后，就要开始“染色”了——用这个口号 去包装一些已有的做法。
例如，2001 年 2 月喊出“敏捷”口号之后，迅速出现一批名为“敏 捷××”的书籍。下面所列出的这些书，名字相当直白（还有很多内容 类似的书名字稍委婉） ：
Agile Software Development， Alistair Cockburn，2001
Agile Modeling，Scott Ambler，2002
Agile Software Development: Principles, Patterns, and Practices，Robert C. Martin，2003
Lean Software Development: An Agile Toolkit ， Mary Poppendieck 等，2003
Agile Management for Software Engineering ， David J. Anderson，2003
Agile Documentation，Andreas Rüping，2003
Agile Database Techniques，Scott Ambler，2003
Agile Software Development，Alan S. Koch，2004
Agile Project Management，Jim Highsmith，2004
Agile Project Management，Gary Chin，2004
Agile Estimating and Planning，Mike Cohn，2005 81
Agile Java，Jeff Langr，2005
Agile Web Development with Rails，David Thomas 等，2005
Agile Development with ICONIX Process，Doug Rosenberg 等，2005
Agile Java Development with Spring, Hibernate and Eclipse， Anil Hemrajani，2006
Agile Systems with Reusable Patterns of Business Knowledge，Amit Mitra 等，2006
Agile Information Systems，Kevin C. Desouza，2006
Agile Software Construction，John Hunt，2006
……
（以上所列书籍，大部分有中译本）
图 1-32 敏捷宣言之后的几年内出版的一些书
82
如果把“敏捷”限于项目管理或过程改进，那还罢了。把面向对象、 数据库、Java、Web 等内容也染上“敏捷”，是一种非常不好的风气。
最典型的是 Robert C. Martin 的“Agile Software Development: Principles, Patterns, and Practices” 。这本书主要讲述的是面向对象 分析设计的一些内容，这些内容非 Robert C. Martin 首先提出，而且 和具体过程没有必然关系，但 Robert C. Martin 的做法使很多开发人 员产生误解，以为这些内容是敏捷圈子的研究成果。
“ Agile Software Development: Principles, Patterns, and Practices”的内容扩展自 Robert C. Martin 于 2000 年在自己网站 objectmentor.com 上 发 表 的 “ Design Principles and Design Patterns” ，Robert C. Martin 在这篇文章中整理了一些他认为比较重 要的“原则”和“模式”。
83
图 1-33 “Design Principles and Design Patterns”截图
★目前，objectmentor.com 已不再有效，在网络上可以下载到
“Design Principles and Design Patterns”文章的地址是：
https://staff.cs.utu.fi/~jounsmed/doos_06/material/DesignP
rinciplesAndPatterns.pdf
“Design Principles and Design Patterns”的几十页内容中，
没有一处提到“agile”（正常，口号还没喊出来呢），也没有一处提到 “light” 、“lightweight” 、“process”或“methodology”，说明 Robert C. Martin 自己非常清楚这些内容写的是什么。
而在他 2003 年的书中，这些内容摇身一变，成了“敏捷软件开发
原则”。读者可以体会一下，Robert C. Martin 是出于什么样的心思。
这二十多年来，我在和各种开发人员打交道的过程中，就因此备受
困扰。
在圈子的强力宣传之下，开发人员变成井底之蛙，以为所谓的
SOLID 原则就是软件设计的法宝，学会了它，就能搞定软件设计的问 题；反过来，如果没搞定，就是因为没理解透这几个原则。
于是，开发团队就来找我给他们讲 SOLID 原则（以及同样出名的
GoF 模式）。碰到这种情况，我也只能如实告知，讲当然没问题，主要 就是一个泛化（继承）的应用，车轱辘话产出这么多内容，但除此之外， 分析设计还有更难也更有价值的内容值得学习。
读者不妨结合前文内容猜一猜，我这样一说之后，开发团队怎么反
84
应的概率最大？
这个“染色”的风气持续到今天。最近几年的各种热点， “敏捷” 都有“染色”——敏捷大数据、敏捷机器学习、敏捷人工智能，如图 1-34。
图 1-34 最近几年出版的紧跟热点的“敏捷”书籍
除了圈子众人主动出击四处“染色”之外，当“敏捷”成为政治正 确时，一些本来在圈子外的方法学家（甚至还包括 UML 三友之一）眼 见口号来势汹汹，于是就带着自己的方法来投靠，宣称“我这个***也 是敏捷的！ ”。
可能有的读者会想，“染色”就“染色”呗，至少人家也推广了面 向对象，推广了某某技术。
85
并非如此，高喊某个口号就能占尽大义，过一段时间被识破了，再 换个词“染色” ，这样的风气往往会导致劣币驱逐良币，最终导致科学 技术停滞甚至倒退。
幸好目前还没有敏捷数学、敏捷物理、敏捷化学。
更多阐述参见我的这些文章：
《潘老师有点理想化了，现实中程序员很菜的占多数》
https://mp.weixin.qq.com/s/UHqAwxOP78yLOHlmJdSxmw
《“以炮换马”的 DDD 歪招是否可以作为起步》
https://mp.weixin.qq.com/s/MyXRDlox5wN4ycOuBxJdtQ
做事情的方式：有口号有方法、有口号无方法、无口号无方法，哪 一种最坏？
可能有的人会认为无口号无方法最坏，其实不然。无口号无方法地 呆在原地，可能会慢慢衰落，但不是最坏的。
历史上各种最坏的大悲剧往往和“有口号无方法”有关——最坏 的事是“有口号无方法”的“好人”做的。
“坏人”知道自己做的是坏事，会暗自收敛，事后会内疚，甚至做 一些善事来弥补以求心安。比如，强盗打家劫舍抢了一千万，可能会拿 出五十万来“济贫”，剩下九百五十万自己爽。这样，他心里就觉得自 己是“侠盗” 。
86
而“好人”认为自己是做好事，既然做好事，那出手就不要有顾虑 了，做得越绝越好，所以可能会做得很极端。如果有口号无方法，大悲 剧就发生了。
软件开发行业如果不警惕“有口号无方法” ，可能会有以下危险：
（1）无意识的自我陶醉
很多产品经理会喊口号：我们只做最重要的需求，尽快把系统推向 市场；
很多架构师会喊口号：设计要分离变和不变，这样可以减少变更的 成本。
问题来了：
怎样知道哪个需求最重要？拍脑袋？
怎样知道哪些变哪些不变？抓阄？
可惜，有的人喊完口号之后，就满足了，陶醉了，觉得自己太牛× 了，这么厉害的道理都懂，足矣，其他都是小意思了。他们并不认真思 考怎样才能真正做到，连自己以前采用的一些虽然不是很好但还过得去 的做法也懒得做了。
200*年，有一位网络名人，北京大学计算机科学博士说过一段话：
关于软件工程，我并不看重。我更相信人对代码的控制能力，正常 人对于正常复杂程度的代码，控制几十万行代码应该是可以的；如果软 件总体上有很好的结构设计，模块之间有稳定、合理的接口，那么，仅 仅依靠人的脑袋，加上良好的编程习惯，即使面对大型的软件，应该也 87
能控制。
问题来了：
“很好的结构设计，模块之间有稳定、合理的接口” 、“良好的编程 习惯”怎么来的？从天上掉下来的？这不正是软件工程研究的学问吗？ 上面这段话就是正确无用的废话。
如果不具备基本的经济学常识，不要说计算机科学博士，就算是 院士，针对软件开发发表的言论都有可能是错得离谱的。
（2）有意识的胡作非为
这是最坏的情况。
因为口号是正确的，在口号的遮掩下胡作非为就很难阻挡，而且后 果也不好追责，毕竟“初衷是好的” ，就像前面提到的那位女生天真无 邪的脸。
88
89
第 8 章 分析 之 分析类图——知识篇
墙上挂了根长藤，长藤上面挂铜铃
《长藤挂铜铃》 ；词：元庸，曲：梅翁（姚敏），唱：逸敏，1959
从分析工作流开始，我们每个内容都分为两章。一章讲述建模知识， 一章讲述建模知识如何应用在本书案例中。这样的分割主要考虑到更符 合实际的工作。
例如，在讲解分析类图时，我们讲解知识的顺序是这样的：
（1）识别类和属性
（2）审查类和属性
（3）识别类之间的泛化
（4）识别类之间的关联
如果把案例剖析分解到每个知识点，为了让案例的剖析符合内容的 顺序，可能就会出现这样的情况：
讲解完识别类和属性后，案例剖析时，先列出很多类和属性，但没 有泛化和关联关系，因为类的关系还没有讲到，所以即使观察到，也故 意不画上去；接下来，讲解完类的关系后，案例剖析时，再把关系加上。
这不符合实际工作中的情况。实际工作中，以上列出的几项工作看 起来是交叉进行的。
我们在识别类和属性的过程中，可能会发现一些类有相同的属性， 90