用口号代替方法-《软件方法》全流程引领AI-第1章 07-优快云博客

第1章 ABCD工作流

1.5.4 运作

以下做事情的方式：有口号有方法、有口号无方法、无口号无方法，哪一个方式最坏？

可能有的人会认为无口号无方法最坏，其实不然。无口号无方法地呆在原地，可能会慢慢衰落，但不是最坏的。

历史上各种最坏的事情往往和“有口号无方法”有关——最坏的事是“有口号无方法”的“好人”做的。

“坏人”知道自己做的是坏事，会暗自收敛，事后会内疚，甚至做一些善事来弥补以求心安。比如，强盗打家劫舍抢了一千万，可能会拿出五十万来“济贫”，剩下九百五十万自己爽。这样，他心里就觉得自己是“侠盗”。

而“好人”认为自己是做好事，既然做好事，那出手就不要有顾虑了，做得越绝越好，所以可能会做得很极端。如果有口号无方法，大悲剧就发生了。

软件开发行业如果不警惕“有口号无方法”，可能会有以下危险：

（1）无意识的自我陶醉

很多产品经理会喊口号：我们只做最重要的需求，尽快把系统推向市场；

很多架构师会喊口号：设计要分离变和不变，这样可以减少变更的成本。

问题来了：

怎样知道哪个需求最重要？拍脑袋？

怎样知道哪些变哪些不变？抓阄？

可惜，有的人喊完口号之后，就满足了，陶醉了，觉得自己太牛×了，这么厉害的道理都懂，其他都是小意思了，到矣尽矣，蔑以加矣。他们并不认真思考怎样才能真正做到，连自己以前采用的一些虽然不是很好但还过得去的做法也懒得做了。

200*年，有一位网络名人，北京大学计算机科学博士说过一段话：

关于软件工程，我并不看重。我更相信人对代码的控制能力，正常人对于正常复杂程度的代码，控制几十万行代码应该是可以的；如果软件总体上有很好的结构设计，模块之间有稳定、合理的接口，那么，仅仅依靠人的脑袋，加上良好的编程习惯，即使面对大型的软件，应该也能控制。

问题来了：

“很好的结构设计，模块之间有稳定、合理的接口”、“良好的编程习惯”怎么来的？从天上掉下来的？这不正是软件工程研究的学问吗？上面这段话就是正确无用的废话。

如果不具备基本的经济学常识，不要说计算机科学博士，就算是院士，针对软件开发发表的言论都有可能是错得离谱的。

（2）有意识的胡作非为

这是最坏的情况。

因为口号是正确的，在口号的遮掩下胡作非为就很难阻挡，而且后果也不好追责。

前文描述过的场景：嫌画类图、状态机图不“敏捷”，一上手就直接编码，然后对着编码环境反复折腾；嫌UML不“敏捷”，自己手画或用绘图工具做自编草图，花的时间比用建模工具点几下还多……其实就是反智和掩盖无能的遮羞布，但没关系，“毕竟初衷是好的”。

★有一次我评点客户开发人员提交的工件，顺便批评了他们团队中一些打着“敏捷”旗号的粗陋做法。然后，一位女生天真无邪地问我，“老师，希望敏捷一些难道不好吗？”——我还能怎么说！“敏捷”这个词本身就是褒义的。它占领了正能量高地，让人无法反对。

★此处提到“女生”，没有歧视的意思，只是如果让我想个例子，我印象最深的就是这个。

在陈述事实的基础上，才可能有合理的讨论。像下表中这些，都是陈述事实：

图1-43 陈述事实的用词

面向过程好还是面向对象好？或者什么情况下面向过程会好一点，什么情况下面向对象会好一点？民营企业好还是国有企业好？或者什么行业适合民营企业，什么行业适合国有企业？或者什么发展阶段优先发展哪一个？

这些都可以讨论。

“敏捷”就不一样了，它直接上了一个褒义词。这个褒义词的对面是什么？迟缓？笨拙？你还怎么讨论呢？它已经立于不败之地了。

可能有的人会说，“敏捷”的对面是“瀑布”啊！前面的段落“割裂历史”已说过，“瀑布”对面其实是“迭代”、“增量”这样阐述具体做法的词——这也是本来已经在用的词，但“敏捷”把它们抹掉，直接上一个褒义词来降维打击。

在“敏捷”口号之前，那些后来被称为“敏捷”的过程，叫做“轻量（Lightweight）”过程。

“轻量”虽然也是一个形容词，但还是比较中性的。就像我们说一个公司是小公司，从员工数量、注册资金或营业额上看，事实确实如此，但如果说公司是“敏捷公司”，味道就大不相同。也许是因为“轻量”的煽动性不够，圈子选择了“敏捷（agile）”。

★近年圈子使用的褒义词还有“精益”、“现代”、“活”等（欢迎读者补充更多资料）。