做软件的人，不管你是管理者、业务人员、需求分析人员、开发人员、测试人员、运维人员，在IT技术和过程推陈出新和突飞猛进的时代，很容易被人忽悠。你是不是经常发现，出于从众心理，你投入时间和金钱，读书和听课，学习并实践了身边其他人所热捧的新技术和新过程，从设计思维，到敏捷，到精益，到DevOps，到持续交付，到TDD，到DDD，到整洁架构，到基础设施即代码，到混沌工程，到AIGC。学了和用了一圈下来，结果发现，*软件质量仍然较差，用户价值仍然较低，软件交付仍然延期*。你感觉被人忽悠了。

如何才能不被忽悠？

如何才能不被别人忽悠？方法只有一个，就是*用科学方法自己动手做实验*，来验证书上和大佬所说的技术和过程，能不能提升自己的软件质量和用户价值。

有人会说，我就是一边学技术和过程，一边在实践呀。实践出真知呀。

没错。你肯实践，就能甩开只读书而不动手的人好几条街。但如果只是实践，而不安排没有做这个实践的*对照组*，怎么知道实践新技术和过程后的成效，要好于原来旧的方式，从而让其他人信服？

咱们拿敏捷试点举例子。有几个企业在做敏捷试点的时候，能安排一个不引入任何敏捷实践的团队，做对照组，来验证敏捷实践的实际成效呢？经常是领导只安排一两个团队当引入敏捷实践的“实验组”做“试点”，而不安排对照组团队。做了一段时间后，把试点团队的度量数据整理一下，作为试点成效汇报上去，就开始推广，并不考虑与对照组团队做对比。

有人会说，可以把实验组的试点团队在试点前和试点后的数据进行对比呀。这样说听起来合理，但这样对比有个问题，就是试点团队在试点前，根本就没有度量试点期间需要度量的指标。为了营造试点后良好的成效，此时经常会靠拍脑袋，把试点前的数据写得低一些，让试点的成效皆大欢喜。

但此时，如果实际成效与试点前相比，几乎持平，甚至更差，一般就没有人敢仗义执言了。此时，团队成员心里，都觉得自己被忽悠了。

还有人会说，找个与试点团队相似的团队，作为对照组，太麻烦了。可以不设置对照组，而在试点团队结束试点后，找其中的团队成员访谈一下，问问他们是否觉得敏捷实践有帮助，就行了。

这个方法虽然简单，但其中隐藏着两个很大的问题。，团队成员在访谈中，出于社会情境的压力，在从众心理的驱使下，只会说敏捷实践的好话。毕竟领导要求大家支持敏捷试点嘛。第二，访谈的结果只能揭示相关性，而无法揭示因果关系。我们知道，两个事物相关，并不等同于它们之间存在因果关系。*相关性不等同于因果性*。要想*揭示因果关系，只能靠有对照组的科学实验*。

为什么人们都热衷于寻找因果关系？因为只有这样，才能让人产生*可感知的控制感*，进而能满足人天生具有的*自主作出选择的需求*。

如何做好科学实验？

如何才能做好有对照组的科学实验？有如下6步。

1 基于观察

2 问出问题

3 形成可验证的解释性假说

4 基于假说做出预测

5 设计并执行有对照组的实验，验证预测

6 根据实验结果可回到第3步，不断迭代优化假说或预测

用科学方法做实验，不仅可以用于验证敏捷是不是在忽悠人，还可以用于验证你在书中读到的技术和过程是不是在忽悠人。

假设你在书中读到了这么一段：Docker利用chroot这个Unix系统调用，来为每个进程分配各自的根目录，用来隔离这些进程。

该如何用上面6步，设计一个科学实验，验证一下这段文字是不是在忽悠人？

1 基于观察。

我读到“Docker利用chroot这个Unix系统调用，来为每个进程分配各自的根目录，用来隔离这些进程。”

2 问出问题。

我可以问：“运行在电脑上的docker容器，其中的文件系统，与其宿主电脑上的文件系统，是隔离的吗？”

3 形成可验证的解释性假说。

我可以这样提出解释性假说：“Docker利用chroot这个Unix系统调用，为每个进程单独分配一个根目录，用来保存这个进程的所有文件，从而实现进程之间的隔离。”

4 基于假说做出预测。

我可以这样做出预测：“当我在电脑上运行一个Docker容器后，容器内特定文件夹中的特定文件内容，应该与宿主电脑上相同文件夹的相同文件中的内容不同。因为这样才能体现隔离性。”

5 设计并执行有对照组的实验，验证预测。

我可以将宿主电脑Ubuntu系统，当作一个对照组，并执行下面的命令，查看文件/etc/issue的行，获取操作系统版本号信息。

head -n1 /etc/issue

我了解到宿主电脑的Ubuntu版本是：

Ubuntu 22.04.2 LTS \n \l

然后我在宿主电脑上通过以下命令，运行一个Docker容器，并把它当作实验组。

docker run --name firstcontainer -ti --rm alpine:3.11 /bin/sh

这行命令会根据alpine 3.11镜像，运行一个名为firstcontainer的容器。并且能在命令执行后，打开一个命令行界面，用来操作容器内的文件。

然后我在容器内的命令行界面，执行与宿主机同样的命令，来查看容器的操作系统版本号。

head -n1 /etc/issue

命令运行结果告诉我，容器内的Linux系统版本是：

Welcome to Alpine Linux 3.11

6 根据实验结果可回到第3步，不断迭代优化假说或预测。

实验结果表明，对于同样目录同样文件名的/etc/issue文件的行，对照组和实验组的结果不一致。这支持了第3步的假说。我可以视支持的情况，不断迭代和优化实验。

总结一下。*读书*虽然能很快得到结论，但*难以说明*结论一定适用于你，且*难以揭示*结论背后的原因。*访谈*只能揭示相关性，无法揭示因果性。*相关性不等同于因果性*。揭示因果性的*方法*，就是*用科学方法做实验*。你用科学方法，做具备对照组的实验，来验证书上或大佬所说的结论，是否名副其实。这才是做软件的人，不被他人忽悠的方法。

如果觉得本文对你有帮助，欢迎*点赞*，点击*在读*，并*转发*给其他经常受他人忽悠之害的小伙伴。*你觉得做软件的人，要想不被忽悠，还有什么其他好办法*？*你还希望我聊有关做软件的其他什么新话题*？欢迎在评论区*留言*。我会仔细阅读每一条留言。期待听到你的声音。

*企业生意蒸蒸日上，软件系统稳定运行*。你所阅读的文章，来自“吾真本说混沌工程”知乎专栏。