1.5 警惕和揭秘伪创新
1.5.2 伪创新的特点
1.5.2.3 用口号代替方法
选择一个让人无法反驳的口号，通过圈子的力量宣传这个口号，占据舆论高地。
然后，再慢慢用这个口号来选择性地包装一些已有的方法，成为圈子的“创新”。
口号可以是一个褒义词，例如，“敏捷（agile）”。
★近年圈子使用的褒义词还有“精益”、“现代”、“活”等（欢迎读者补充更多资料）。
有一次我评点客户开发人员提交的工件，顺便批评了他们团队中一些打着“敏捷”旗号的粗陋做法。然后，一位女生天真无邪地问我，“老师，希望敏捷一些难道不好吗？”——此处提到“女生”，没有歧视的意思，只是如果让我想个例子，我印象最深的就是这个。
我还能怎么说！“敏捷”这个词本身就是褒义的。它占领了正能量高地，让人无法反对。
在陈述事实的基础上，才可能有合理的讨论。像下表中这些，都是陈述事实：
图1-28 陈述事实的用词
面向过程好还是面向对象好？或者什么情况下面向过程会好一点，什么情况下面向对象会好一点？民营企业好还是国有企业好？或者什么行业适合民营企业，什么行业适合国有企业？或者什么发展阶段优先发展哪一个？
这些都可以讨论。
“敏捷”就不一样了，它直接上了一个褒义词。这个褒义词的对面是什么？迟缓？笨拙？你还怎么讨论呢？它已经立于不败之地了。
可能有的人会说，“敏捷”的对面是“瀑布”啊！
“瀑布”对面其实是“迭代”、“增量”这样阐述具体做法的词——这也是本来已经在用的词，但“敏捷”把它们抹掉（后面的段落“割裂历史和封闭引用”还会详述），直接上一个褒义词来降维打击。
在“敏捷”口号之前，那些后来被称为“敏捷”的过程，叫做“轻量（Lightweight）”过程。
“轻量”虽然也是一个形容词，但还是比较中性的。就像我们说一个公司是小公司，从员工数量、注册资金或营业额上看，事实确实如此，但如果说公司是“敏捷公司”，味道就大不相同。也许是因为“轻量”的煽动性不够，圈子选择了“敏捷（agile）”。
★“敏捷（agile）”并非软件业特定圈子首先使用。1991年，制造业就有“敏捷制造”、“敏捷企业”的口号，如图1-29。不知道软件业圈子是有意借鉴还是不谋而合。
图1-29 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
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-30 敏捷宣言之后的几年内出版的一些书
如果把“敏捷”限于项目管理或过程改进，那还罢了。把面向对象、数据库、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在这篇文章中整理了一些他认为比较重要的“原则”和“模式”。
图1-31 “Design Principles and Design Patterns”截图
★目前，objectmentor.com已不再有效，在网络上可以下载到“Design Principles and Design Patterns”文章的地址是：
https://staff.cs.utu.fi/~jounsmed/doos_06/material/DesignPrinciplesAndPatterns.pdf
“Design Principles and Design Patterns”的几十页内容中，没有一处提到“agile”（正常，口号还没喊出来呢），也没有一处提到“light”、“lightweight”、“process”或“methodology”，说明Robert C. Martin自己非常清楚这些内容写的是什么。
而在他2003年的书中，这些内容摇身一变，成了“敏捷软件开发原则”。
这二十多年来，我在和各种开发人员打交道的过程中，就因此备受困扰。
在圈子的强力宣传之下，开发人员变成井底之蛙，以为所谓的SOLID原则就是软件设计的法宝，学会了它，就能搞定软件设计的问题；反过来，如果没搞定，就是因为没理解透这几个原则。
于是，开发团队就来找我给他们讲SOLID原则（以及同样出名的GoF模式）。碰到这种情况，我也只能如实告知，讲当然没问题，主要就是一个泛化（继承）的应用，车轱辘话产出这么多内容，但除此之外，分析设计还有更难也更有价值的内容值得学习。
读者不妨结合前文内容猜一猜，我这样一说之后，开发团队怎么反应的概率最大？
这个“染色”的风气持续到今天。最近几年的各种热点，“敏捷”都有“染色”——敏捷大数据、敏捷机器学习、敏捷人工智能，如图1-32。
图1-32 最近几年出版的紧跟热点的“敏捷”书籍
除了圈子众人主动出击四处“染色”之外，当“敏捷”成为政治正确时，一些本来在圈子外的方法学家眼见口号来势汹汹，于是就带着自己的方法来投靠，宣称“我这个***也是敏捷的！”。
**********
可能有的读者会想，“染色”就“染色”呗，至少人家也推广了面向对象，推广了某某技术。
并非如此，高喊某个口号就能占尽大义，过一段时间被识破了，再换个词“染色”，这样的风气往往会导致劣币驱逐良币，最终导致科学技术停滞甚至倒退。
幸好目前还没有敏捷数学、敏捷物理、敏捷化学。
更多阐述参见：
**********
做事情的方式：有口号有方法、有口号无方法、无口号无方法，哪一种最坏？
可能有的人会认为无口号无方法最坏，其实不然，无口号无方法地呆在原地，可能会慢慢衰落，但不是最坏的。历史上各种最坏的大悲剧往往和“有口号无方法”有关——最坏的事是“有口号无方法”的“好人”做的。
“坏人”知道自己做的是坏事，会暗自收敛，事后会内疚，甚至做一些善事来弥补以求心安。比如，强盗打家劫舍抢了一千万，可能会拿出五十万来“济贫”，剩下九百五十万自己爽。这样，他心里就觉得自己是“侠盗”。
而“好人”认为自己是做好事，既然做好事，那出手就不要有顾虑了，做得越绝越好，所以可能会做得很极端。如果有口号无方法，大悲剧就发生了。
软件开发行业如果不警惕“有口号无方法”，可能会有以下危险：
（1）无意识的自我陶醉
很多产品经理会喊口号：我们只做最重要的需求，尽快把系统推向市场；
很多架构师会喊口号：设计要分离变和不变，这样可以减少变更的成本。
问题来了：
怎样知道哪个需求最重要？拍脑袋？
怎样知道哪些变哪些不变？抓阄？
可惜，有的人喊完口号之后，就满足了，陶醉了，觉得自己太牛×了，这么厉害的道理都懂，足矣，其他都是小意思了。他们并不认真思考怎样才能真正做到，连自己以前采用的一些虽然不是很好但还过得去的做法也懒得做了。
200*年，有一位网络名人，北京大学计算机科学博士说过一段话：
关于软件工程，我并不看重。我更相信人对代码的控制能力，正常人对于正常复杂程度的代码，控制几十万行代码应该是可以的；如果软件总体上有很好的结构设计，模块之间有稳定、合理的接口，那么，仅仅依靠人的脑袋，加上良好的编程习惯，即使面对大型的软件，应该也能控制。
问题来了：
“很好的结构设计，模块之间有稳定、合理的接口”、“良好的编程习惯”怎么来的？从天上掉下来的？这不正是软件工程研究的学问吗？上面这段话就是正确无用的废话。
如果不具备基本的经济学常识，不要说计算机科学博士，就算是院士，针对软件开发发表的言论都有可能是错得离谱的。
（2）有意识的胡作非为
这是最坏的情况。
因为口号是正确的，在口号的遮掩下胡作非为就很难阻挡，而且后果也不好追责，毕竟“初衷是好的”，就像前面提到的那位女生天真无邪的脸。
2832
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
