做软件的人不被他人忽悠的唯一方法
做软件的人，不管你是管理者、业务人员、需求分析人员、开发人员、测试人员、运维人员，在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.116 根据实验结果可回到第3步，不断迭代优化假说或预测。
实验结果表明，对于同样目录同样文件名的/etc/issue文件的第一行，对照组和实验组的结果不一致。这支持了第3步的假说。我可以视支持的情况，不断迭代和优化实验。
总结一下。读书虽然能很快得到结论，但难以说明结论一定适用于你，且难以揭示结论背后的原因。访谈只能揭示相关性，无法揭示因果性。相关性不等同于因果性。揭示因果性的唯一方法，就是用科学方法做实验。你用科学方法，做具备对照组的实验，来验证书上或大佬所说的结论，是否名副其实。这才是做软件的人，不被他人忽悠的唯一方法。
如果觉得本文对你有帮助，欢迎点赞，点击在读，并转发给其他经常受他人忽悠之害的小伙伴。你觉得做软件的人，要想不被忽悠，还有什么其他好办法？你还希望我聊有关做软件的其他什么新话题？欢迎在评论区留言。我会仔细阅读每一条留言。期待听到你的声音。
企业生意蒸蒸日上，软件系统稳定运行。你所阅读的文章，来自“吾真本说混沌工程”知乎专栏。